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

From Ashutosh Bapat
Subject Re: tablecmds.c/MergeAttributes() cleanup
Date
Msg-id CAExHW5tiRmNLSGnKQ2BqK+k4i54FsU_DNSQnqSvW9yEQxXNe8A@mail.gmail.com
Whole thread Raw
In response to Re: tablecmds.c/MergeAttributes() cleanup  (Peter Eisentraut <peter@eisentraut.org>)
List pgsql-hackers


On Fri, May 3, 2024 at 2:47 PM Peter Eisentraut <peter@eisentraut.org> wrote:
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.


Thanks Peter.

--
Best Wishes,
Ashutosh Bapat

pgsql-hackers by date:

Previous
From: Adrien Nayrat
Date:
Subject: Re: different engine for JIT
Next
From: Richard Guo
Date:
Subject: Re: A problem about partitionwise join