Philip Warner <[EMAIL PROTECTED]> writes:
> I think it needs to dump ONLY the overridden settigns, since a change to
> the overriding behaviour of a child seems like a bad thing.
I was about to say it's not worth the trouble, but I see you already
did it ...
regards, tom
At 23:57 2/04/01 -0400, Tom Lane wrote:
>
>NOT NULL on a child field would only force it to be dumped if none
>of the parents say NOT NULL. Type name really is not an issue since
>it will have to be the same in all the tables anyway; I wouldn't bother
>expending any code there.
>
Done & applied
At 23:57 2/04/01 -0400, Tom Lane wrote:
>
>NOT NULL on a child field would only force it to be dumped if none
>of the parents say NOT NULL. Type name really is not an issue since
>it will have to be the same in all the tables anyway; I wouldn't bother
>expending any code there.
>
I've made tha c
Philip Warner <[EMAIL PROTECTED]> writes:
> At 13:27 2/04/01 -0400, Tom Lane wrote:
>> Philip: the rule that pg_dump needs to apply w.r.t. defaults for
>> inherited fields is that if an inherited field has a default and
>> either (a) no parent table supplies a default, or (b) any parent
>> table s
At 13:27 2/04/01 -0400, Tom Lane wrote:
>
>Philip: the rule that pg_dump needs to apply w.r.t. defaults for
>inherited fields is that if an inherited field has a default and
>either (a) no parent table supplies a default, or (b) any parent
>table supplies a default different from the child's, then
[EMAIL PROTECTED] (Nathan Myers) writes:
> On Sat, Mar 31, 2001 at 07:44:30PM -0500, Tom Lane wrote:
>> That is:
>>
>> create table p1 (f1 int default 1);
>> create table p2 (f1 int default 2);
>> create table c1 (f2 float) inherits(p1, p2); # XXX
>>
>> would draw an error about conflicting de
On Mon, Apr 02, 2001 at 01:27:06PM -0400, Tom Lane wrote:
> Philip: the rule that pg_dump needs to apply w.r.t. defaults for
> inherited fields is that if an inherited field has a default and
> either (a) no parent table supplies a default, or (b) any parent
> table supplies a default different fr
On Sun, Apr 01, 2001 at 03:15:56PM -0400, Tom Lane wrote:
> Christopher Masto <[EMAIL PROTECTED]> writes:
> > Another thing that seems kind of interesting would be to have:
> > CREATE TABLE base (table_id CHAR(8) NOT NULL [, etc.]);
> > CREATE TABLE foo (table_id CHAR(8) NOT NULL DEFAULT 'foo');
On Sat, Mar 31, 2001 at 07:44:30PM -0500, Tom Lane wrote:
> [EMAIL PROTECTED] (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
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> 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
Tom Lane writes:
> 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 er
Christopher Masto <[EMAIL PROTECTED]> writes:
> Another thing that seems kind of interesting would be to have:
> CREATE TABLE base (table_id CHAR(8) NOT NULL [, etc.]);
> CREATE TABLE foo (table_id CHAR(8) NOT NULL DEFAULT 'foo');
> CREATE TABLE bar (table_id CHAR(8) NOT NULL DEFAULT 'bar');
> T
At 21:00 31/03/01 -0500, Tom Lane wrote:
>
>If we change the code again based on the latest discussion, then pg_dump
>would have to detect whether there are conflicting defaults, which would
>mean looking at all the parents not just the rightmost one. Ugh. That
>might be a good reason not to cha
At 20:25 31/03/01 -0500, Tom Lane wrote:
>
>> That's what I meant; can we easily do the 'not in the parent' part, since
>> we may have to go up a long hierarchy to find the parent?
>
>pg_dump must already contain code to traverse the inheritance hierarchy
>(I haven't looked to see where). Couldn'
On Fri, Mar 30, 2001 at 12:10:59PM -0500, Tom Lane wrote:
> Comments? I'm going to implement and commit this today unless I hear
> loud squawks ...
I like it in general and I think it opens some interesting
possibilities. I don't know much about how the inheritance system is
implemented, so I w
At 20:40 31/03/01 -0500, Tom Lane wrote:
>Philip Warner <[EMAIL PROTECTED]> writes:
>> You are correct; flagInhAttrs in common.c does the work, and it should be
>> easy to change. At the moment it extracts all tables attrs then looks for
>> an attr with the same name in any parent table. We can ex
Philip Warner <[EMAIL PROTECTED]> writes:
> Looks like it; and just to confirm, based on previous messages, I assume I
> should look at the parents from right to left?
At the moment that would be the right thing to do.
If we change the code again based on the latest discussion, then pg_dump
woul
Philip Warner <[EMAIL PROTECTED]> writes:
> You are correct; flagInhAttrs in common.c does the work, and it should be
> easy to change. At the moment it extracts all tables attrs then looks for
> an attr with the same name in any parent table. We can extend this to check
> NOT NULL and DEFAULT. Sh
Philip Warner <[EMAIL PROTECTED]> writes:
> At 20:02 31/03/01 -0500, Tom Lane wrote:
>> Perhaps we should just hack that code
>> to not suppress inherited attrs when they have default values and/or
>> NOT NULL that's not in the parent.
> That's what I meant; can we easily do the 'not in the paren
At 20:02 31/03/01 -0500, Tom Lane wrote:
>
>Perhaps we should just hack that code
>to not suppress inherited attrs when they have default values and/or
>NOT NULL that's not in the parent.
That's what I meant; can we easily do the 'not in the parent' part, since
we may have to go up a long hierarc
Philip Warner <[EMAIL PROTECTED]> writes:
> At 01:36 31/03/01 -0500, Tom Lane wrote:
>> which is OK as far as the field set goes, but it loses the additional
>> DEFAULT and NOT NULL information for the child table. Any thoughts on
>> the best way to fix this?
> Can pg_dump easily detect overridd
[EMAIL PROTECTED] (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 iss
[EMAIL PROTECTED] (Nathan Myers) writes:
> Of course PG is different from any O-O language. I don't know if PG
> has an equivalent to the "base-class context". I suppose PG has a long
> history of merging like-named members, and that the issue is just of
> the details of how the merge happens
At 01:36 31/03/01 -0500, Tom Lane wrote:
>
>which is OK as far as the field set goes, but it loses the additional
>DEFAULT and NOT NULL information for the child table. Any thoughts on
>the best way to fix this?
>
Can pg_dump easily detect overridden attrs? If so, we just treat them as
table att
Philip Warner <[EMAIL PROTECTED]> writes:
> Not a squawk as such, but does this have implications for pg_dump?
Good point. With recently-committed changes, try:
regression=# create table p1 (f1 int default 42 not null, f2 int);
CREATE
regression=# create table c1 (f1 int, f2 int default 7) inhe
At 12:10 30/03/01 -0500, Tom Lane wrote:
>
>Comments? I'm going to implement and commit this today unless I hear
>loud squawks ...
>
Not a squawk as such, but does this have implications for pg_dump?
Philip Warner
On Fri, Mar 30, 2001 at 11:05:53PM +0200, Peter Eisentraut wrote:
> Tom Lane writes:
>
> > 3. The new column will have a default value if any of the combined
> > column specifications have one. The last-specified default (the one
> > in the explicitly given column list, or the rightmost parent t
On Fri, Mar 30, 2001 at 12:10:59PM -0500, Tom Lane wrote:
> [EMAIL PROTECTED] (Nathan Myers) writes:
> > The O-O principle involved here is Liskov Substitution: if the derived
> > table is used in the context of code that thinks it's looking at the
> > base table, does anything break?
>
> I propo
Peter Eisentraut <[EMAIL PROTECTED]> writes:
>> 4. All relevant constraints from all the column specifications will
>> be applied. In particular, if any of the specifications includes NOT
>> NULL, the resulting column will be NOT NULL. (But the current
>> implementation does not support inherita
Tom Lane writes:
> 3. The new column will have a default value if any of the combined
> column specifications have one. The last-specified default (the one
> in the explicitly given column list, or the rightmost parent table
> that gives a default) will be used.
This seems pretty random. It wo
[EMAIL PROTECTED] (Nathan Myers) writes:
> The O-O principle involved here is Liskov Substitution: if the derived
> table is used in the context of code that thinks it's looking at the
> base table, does anything break?
Good point. That answers my concern about how to handle typmod: an
applicati
On Thu, Mar 29, 2001 at 02:29:38PM +0100, Oliver Elphick wrote:
> Peter Eisentraut wrote:
> >Tom Lane writes:
> >
> >> It seems that in pre-7.0 Postgres, this works:
> >>
> >> create table one(id int default 1, descr text);
> >> create table two(id int default 2, tag text) inherits (on
"Oliver Elphick" <[EMAIL PROTECTED]> writes:
Although the liberty to do anything you want seems appealing at first, I
would think that allowing this is not correct from an OO point of view.
> I don't agree; this is equivalent to redefinition of a feature (=method) in
> a descendant clas
Oliver Elphick writes:
> Peter Eisentraut wrote:
> >Tom Lane writes:
> >
> >> It seems that in pre-7.0 Postgres, this works:
> >>
> >> create table one(id int default 1, descr text);
> >> create table two(id int default 2, tag text) inherits (one);
> >>
> >> with the net effect th
Peter Eisentraut wrote:
>Tom Lane writes:
>
>> It seems that in pre-7.0 Postgres, this works:
>>
>> create table one(id int default 1, descr text);
>> create table two(id int default 2, tag text) inherits (one);
>>
>> with the net effect that table "two" has just one "id" column wi
Tom Lane writes:
> It seems that in pre-7.0 Postgres, this works:
>
> create table one(id int default 1, descr text);
> create table two(id int default 2, tag text) inherits (one);
>
> with the net effect that table "two" has just one "id" column with
> default value 2.
Although the liberty to d
36 matches
Mail list logo
