Re: tablecmds.c/MergeAttributes() cleanup - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: tablecmds.c/MergeAttributes() cleanup
Date
Msg-id b983b970-2666-4e89-aa6c-ec372603a984@eisentraut.org
Whole thread Raw
In response to Re: tablecmds.c/MergeAttributes() cleanup  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: tablecmds.c/MergeAttributes() cleanup
List pgsql-hackers
On 30.04.24 21:48, Robert Haas wrote:
> I took a look at this patch. Currently this case crashes:
> 
> CREATE TABLE cmdata(f1 text COMPRESSION pglz);
> CREATE TABLE cmdata3(f1 text);
> CREATE TABLE cminh() INHERITS (cmdata, cmdata3);
> 
> The patch makes this succeed, but I was initially unclear why it
> didn't make it fail with an error instead: you can argue that cmdata
> has pglz and cmdata3 has default and those are different. It seems
> that prior precedent goes both ways -- we treat the absence of a
> STORAGE specification as STORAGE EXTENDED and it conflicts with an
> explicit storage specification on some other inheritance parent - but
> on the other hand, we treat the absence of a default as compatible
> with any explicit default, similar to what happens here.

The actual behavior here is arguably not ideal.  It was the purpose of 
the other thread mentioned upthread to improve that, but that was not 
successful for the time being.

> So now I think this is committable, but I can't do it now because I
> won't be around for the next few hours in case the buildfarm blows up.
> I can do it tomorrow, or perhaps Peter would like to handle it since
> it seems to have been his commit that introduced the issue.

I have committed it now.




pgsql-hackers by date:

Previous
From: Alexander Korotkov
Date:
Subject: Re: Removing unneeded self joins
Next
From: Adrien Nayrat
Date:
Subject: Re: different engine for JIT