From: | Nils Gösche <cartan(at)cartan(dot)de> |
---|---|
To: | <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Feature Proposal: Constant Values in Columns or Foreign Keys |
Date: | 2012-04-18 07:18:19 |
Message-ID: | 001601cd1d33$6ec738e0$4c55aaa0$@de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Tom Lane wrote:
> =?UTF-8?Q?Nils_G=C3=B6sche?= <cartan(at)cartan(dot)de> writes:
> > I was quite surprised to find that this wasn't possible. Is there any
> > good reason why not?
>
> It's contrary to SQL standard is why not. And it's not just a matter
> of
> being outside the spec, as inheritance is; this is messing with the
> details of something that is defined in the standard. As an example,
> I would wonder how such an FK is supposed to be represented in the
> spec-defined information schema views. Other interesting questions
> include what would happen to the supposed constant during actions such
> as ON DELETE SET NULL or ON UPDATE CASCADE, which normally would result
> in a change in the referencing row.
Well, something I can have already is a column together with a NOT NULL constraint, and a CHECK constraint that ensures that the value is really constant, and a foreign key that includes this constant column. You could just handle it the same way.
The information schema is a good point, though. If the only way to put this into the information schema is to introduce some dummy column, possibly with NULL as a name or something, then I don't like the idea much myself anymore.
I guess the best I could hope for, then, is an optimization that does not store constant columns on disk ;-)
Regards,
--
Nils Gösche
"Don't ask for whom the <CTRL-G> tolls."
From | Date | Subject | |
---|---|---|---|
Next Message | hubert depesz lubaczewski | 2012-04-18 09:51:18 | Re: Compile docs on ArchLinux |
Previous Message | Roberto De Oliveira | 2012-04-18 04:55:20 | Log to syslog in one line |