From: | ncm(at)zembu(dot)com (Nathan Myers) |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Re: Changing the default value of an inherited column |
Date: | 2001-04-02 21:37:13 |
Message-ID: | 20010402143713.R3797@store.zembu.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Apr 01, 2001 at 03:15:56PM -0400, Tom Lane wrote:
> Christopher Masto <chris(at)netmonger(dot)net> 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');
> > Then a function on "base" could look at table_id and know which
> > table it's working on. A waste of space, but I can think of
> > uses for it.
>
> This particular need is superseded in 7.1 by the 'tableoid'
> pseudo-column. However you can certainly imagine variants of this
> that tableoid doesn't handle, for example columns where the subtable
> creator can provide a useful-but-not-always-correct default value.
A bit of O-O doctrine... when you find yourself tempted to do something
like the above, it usually means you're trying to do the wrong thing.
You may not have a choice, in some cases, but you should know you are
on the way to architecture meltdown. "She'll blow, Cap'n!"
Nathan Myers
ncm(at)zembu(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Myers | 2001-04-02 21:46:16 | Re: Re: Changing the default value of an inherited column |
Previous Message | Nathan Myers | 2001-04-02 21:22:05 | Re: Re: Changing the default value of an inherited column |