Re: Feature Proposal: Constant Values in Columns or Foreign Keys
От | Nils Gösche |
---|---|
Тема | Re: Feature Proposal: Constant Values in Columns or Foreign Keys |
Дата | |
Msg-id | 001601cd1d33$6ec738e0$4c55aaa0$@de обсуждение исходный текст |
Ответ на | Re: Feature Proposal: Constant Values in Columns or Foreign Keys (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-general |
Tom Lane wrote: > =?UTF-8?Q?Nils_G=C3=B6sche?= <cartan@cartan.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 thatthe value is really constant, and a foreign key that includes this constant column. You could just handle it the sameway. The information schema is a good point, though. If the only way to put this into the information schema is to introduce somedummy 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."
В списке pgsql-general по дате отправления: