Re: ALTER TABLE...ALTER COLUMN vs inheritance - Mailing list pgsql-hackers

From Bernd Helmle
Subject Re: ALTER TABLE...ALTER COLUMN vs inheritance
Date
Msg-id D1815DA0B6288201EC1CFAC3@amenophis
Whole thread Raw
In response to Re: ALTER TABLE...ALTER COLUMN vs inheritance  (Alex Hunsaker <badalex@gmail.com>)
List pgsql-hackers

--On 16. November 2009 11:00:33 -0700 Alex Hunsaker <badalex@gmail.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


pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: using separate parameters in psql query execution
Next
From: Joshua Tolley
Date:
Subject: Re: plperl and inline functions -- first draft