Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I suspect domains are one of our least used features, which might
> account for the lack of complaint.
True, and it would also say that the risk of breaking any existing app
is low ...
regards, tom lane
---
Tom Lane wrote:
You have a point, but on reflection I think the odds of this change
breaking an existing application are low. The reason is that in the old
implementation, "DEFAULT NULL" is effectively not there at all, and so
an update to a newer point-release, or even a dump and reload, woul
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> Is it OK to change this behavior? Should I
>> back-patch, or not?
> I would tend to be more conservative than we've been in the past with
> back patching. We keep saying people should be on the most recent
> poi
"Tom Lane" <[EMAIL PROTECTED]> writes:
> AFAICS this is a flat-out bug too, since the per-column default should
> override the domain's default; that's certainly how it works for any
> non-null column default value. But I wasn't expecting any regression
> failures with this patch. Is it OK to ch
I wrote:
> ... I propose stripping out gram.y's special
> hack for this, and preserving the efficiency of the case by
> inserting a test very much later to see if the expression is just
> a NULL constant. Maybe AddRelationRawConstraints is the right place.
I did this (see attached patch) and got
Gregory Stark <[EMAIL PROTECTED]> writes:
> Well if there's a convenient later place to add the check then sure. Will it
> mean pg_dump will have to put DEFAULT NULL everywhere though? Or can it detect
> that it's an inherited table where the default doesn't match?
The latter --- I already committ
"Tom Lane" <[EMAIL PROTECTED]> writes:
> ISTM this is a backend bug: if I tell it DEFAULT NULL, by golly I
> should get DEFAULT NULL. I propose stripping out gram.y's special
> hack for this, and preserving the efficiency of the case by
> inserting a test very much later to see if the expression
Simon Riggs <[EMAIL PROTECTED]> writes:
> Seems more like an unwanted looseness in the meaning of an ALTER
> TABLE .. INHERIT to me. I'd prefer it if we added some extra clauses to
> ALTER TABLE:
> [ { INCLUDING | EXCLUDING } { DEFAULTS | CONSTRAINTS | INDEXES } ]
I think you're confusing this wi
On Sun, 2007-10-28 at 12:44 -0400, Tom Lane wrote:
> While poking at the complaint reported here:
> http://archives.postgresql.org/pgsql-general/2007-10/msg01484.php
> I realized that there is a related issue for null defaults. Consider
>
> create table p (f1 int default 0);
> create
While poking at the complaint reported here:
http://archives.postgresql.org/pgsql-general/2007-10/msg01484.php
I realized that there is a related issue for null defaults. Consider
create table p (f1 int default 0);
create table c (f1 int);
alter table c inherit p;
At this
10 matches
Mail list logo
