Re: [HACKERS] ALTER TABLE...ALTER COLUMN vs inheritance

--On 16. Juni 2010 14:31:00 +0200 Bernd Helmle wrote: There are some spelling and grammar errors in comments that I can help fix if you want the help. You're welcome. I have pushed my branch to my git repos as well, if you like to start from there:

Re: [HACKERS] ALTER TABLE...ALTER COLUMN vs inheritance

--On 15. Juni 2010 20:51:21 -0700 Selena Deckelmann wrote: Confirmed that this tests fine against commit id 0dca7d2f70872a242d4430c4c3aa01ba8dbd4a8c I also wrote a little test script and verified that it throws an error when I try to remove a constraint from the parent table. Thanks for

Re: [HACKERS] ALTER TABLE...ALTER COLUMN vs inheritance

On Wed, Jun 16, 2010 at 5:31 AM, Bernd Helmle wrote: > > > --On 15. Juni 2010 20:51:21 -0700 Selena Deckelmann > wrote: > >> Confirmed that this tests fine against commit id >> 0dca7d2f70872a242d4430c4c3aa01ba8dbd4a8c >> >> I also wrote a little test script and verified that it throws an error >>

Re: [HACKERS] ALTER TABLE...ALTER COLUMN vs inheritance

On Wed, May 26, 2010 at 2:37 PM, Bernd Helmle wrote: > Lost it a little from my radar, but here's is a first shot on this issue > now. The patch creates a new CONSTRAINT_NOTNULL contype and assigns all > required information for the NOT NULL constraint to it. Currently the > constraint records th

Re: [HACKERS] ALTER TABLE...ALTER COLUMN vs inheritance

--On 4. November 2009 09:57:27 -0500 Tom Lane wrote: Yeah, this is a known issue. The ALTER should be rejected, but it is not, because we don't have enough infrastructure to notice that the constraint is inherited and logically can't be dropped. I think the consensus was that the way to fix

Re: [HACKERS] ALTER TABLE...ALTER COLUMN vs inheritance

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

Re: [HACKERS] ALTER TABLE...ALTER COLUMN vs inheritance

On Mon, Nov 16, 2009 at 11:45, Tom Lane wrote: > Alex Hunsaker writes: >> FYI defaults have the same problem.   Would it be awkward would it be >> to use pg_constraint for the book keeping as well? [ and by that I >> really mean ALTER TABLE ADD CONSTRAINT my_default DEFAULT so you >> can giv

Re: [HACKERS] ALTER TABLE...ALTER COLUMN vs inheritance

Alex Hunsaker writes: > FYI defaults have the same problem. Would it be awkward would it be > to use pg_constraint for the book keeping as well? [ and by that I > really mean ALTER TABLE ADD CONSTRAINT my_default DEFAULT so you > can give them a name ] That sounds moderately insane to me.

Re: [HACKERS] ALTER TABLE...ALTER COLUMN vs inheritance

On Thu, Nov 12, 2009 at 11:56, Bernd Helmle wrote: > I've just started looking into this and wonder how this should look like. IIRC another motivation for moving them into pg_constraint was we could then give them names as required by the spec (unless I got mixed up with defaults). Looking at th

Re: [HACKERS] ALTER TABLE...ALTER COLUMN vs inheritance

Alex Hunsaker writes: > On Thu, Nov 12, 2009 at 13:55, Tom Lane wrote: >> I'd go for the first of those, for sure.  Testing attnotnull is >> significantly cheaper than enforcing a generic constraint expression, >> and NOT NULL is a sufficiently common case to be worth worrying about >> optimizin

Re: [HACKERS] ALTER TABLE...ALTER COLUMN vs inheritance

On Thu, Nov 12, 2009 at 13:55, Tom Lane wrote: > I'd go for the first of those, for sure.  Testing attnotnull is > significantly cheaper than enforcing a generic constraint expression, > and NOT NULL is a sufficiently common case to be worth worrying about > optimizing it. When I looked at doing

Re: [HACKERS] ALTER TABLE...ALTER COLUMN vs inheritance

Bernd Helmle writes: > My first idea is to just introduce a special contype in pg_constraint > representing a NOT NULL constraint on a column, which holds all required > information to do the mentioned maintenance stuff on them and to keep most > of the current infrastructure. Utility commands

Re: [HACKERS] ALTER TABLE...ALTER COLUMN vs inheritance

--On 4. November 2009 09:57:27 -0500 Tom Lane wrote: I think the consensus was that the way to fix this (along with some other problems) is to start representing NOT NULL constraints in pg_constraint, turning attnotnull into just a bit of denormalization for performance. I've just started

Re: [HACKERS] ALTER TABLE...ALTER COLUMN vs inheritance

--On 4. November 2009 09:57:27 -0500 Tom Lane wrote: I think the consensus was that the way to fix this (along with some other problems) is to start representing NOT NULL constraints in pg_constraint, turning attnotnull into just a bit of denormalization for performance. Ah okay, should hav

Re: [HACKERS] ALTER TABLE...ALTER COLUMN vs inheritance

Bernd Helmle writes: > Consider the following workflow: > CREATE TABLE foo(id integer NOT NULL, val text NOT NULL); > CREATE TABLE foo2(another_id integer NOT NULL) INHERITS(foo); > Now someone decides he doesn't want the NOT NULL constraint on the > inherited column "val" anymore: > ALTER TAB

[HACKERS] ALTER TABLE...ALTER COLUMN vs inheritance

I just run across an issue with ALTER TABLE and inheritance (i don't know wether this is of the same kind of issue KaiGai reported today, so i keep it on a separate thread). Consider the following workflow: CREATE TABLE foo(id integer NOT NULL, val text NOT NULL); CREATE TABLE foo2(another_i