Re: Re: Changing the default value of an inherited column
От | Tom Lane |
---|---|
Тема | Re: Re: Changing the default value of an inherited column |
Дата | |
Msg-id | 28145.986085870@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Re: Changing the default value of an inherited column (ncm@zembu.com (Nathan Myers)) |
Ответы |
Re: Re: Changing the default value of an inherited column
Re: Re: Changing the default value of an inherited column |
Список | pgsql-hackers |
ncm@zembu.com (Nathan Myers) writes: >> This seems pretty random. It would be more reasonable if multiple >> (default) inheritance weren't allowed unless you explicitly specify a new >> default for the new column, but we don't have a syntax for this. > I agree, but I thought the original issue was that PG _does_ now have > syntax for it. Any conflict in default values should result in either > a failure, or "no default". Choosing a default randomly, or according > to an arbitrary and complicated rule (same thing), is a source of > bugs. Well, we *do* have a syntax for specifying a new default (the same one that worked pre-7.0 and does now again). I guess what you are proposing is the rule "If conflicting default values are inherited from multiple parents that each define the same column name, then an error is reported unless the child table redeclares the column and specifies a new default to override the inherited ones". That is: create table p1 (f1 int default 1);create table p2 (f1 int default 2);create table c1 (f2 float) inherits(p1, p2); would draw an error about conflicting defaults for c1.f1, but create table c1 (f1 int default 3, f2 float) inherits(p1, p2); would be accepted (and 3 would become the default for c1.f1). This would take a few more lines of code, but I'm willing to do it if people think it's a safer behavior than picking one of the inherited default values. regards, tom lane
В списке pgsql-hackers по дате отправления: