Re: ALTER TABLE...ALTER COLUMN vs inheritance

From: Bernd Helmle <mailings(at)oopsware(dot)de>
To: Alex Hunsaker <badalex(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: ALTER TABLE...ALTER COLUMN vs inheritance
Date: 2009-11-16 22:10:08
Message-ID: D1815DA0B6288201EC1CFAC3@amenophis
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

--On 16. November 2009 11:00:33 -0700 Alex Hunsaker <badalex(at)gmail(dot)com>
wrote:

> Anyway Bernd if you are working on this great! If not lemme know, Ill
> plan on having something for the next commit feast. Though I still
> may never get around to it :(.

I'm just working on it.

The current patch assigns <tablename>_<col>_not_null (by using
ChooseConstraintName()) as the constraint name to NOT NULL, i record the
attnum this NOT NULL belongs to in conkey. So far so good, creating the
constraints already works, i'm going to adjust the utility commands now.
One thing i just stumpled across: I guess we want the same behavior for
dropping NOT NULL constraints recursively like we already do for CHECK
constraints.

I thought i can reuse some of the infrastructure of ATExecDropConstraint(),
but this seems somekind awful, since it requires a constraint name and we
already did the scanning of pg_constraint up to this point. Since i don't
like duplicating too much code i'm thinking about splitting
ATExecDropConstraint() in an additional function
ATExecDropConstraintInternal(), which does the real work for a given
constraint OID.

--
Thanks

Bernd

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Joshua Tolley 2009-11-16 22:19:45 Re: plperl and inline functions -- first draft
Previous Message Pavel Stehule 2009-11-16 22:01:44 using separate parameters in psql query execution