Geoff Winkless, 07.02.2013 11:46:
On 7 February 2013 09:38, Chris Travers <chris.trav...@gmail.com
<mailto:chris.trav...@gmail.com>> wrote:
1: The foreign key depends on the function so the function cannot be
dropped first absent CASCADE
2: If the function is redefined, one would have to check all rows to
verify that they meet the new function's requirements. This could
pose a performance issue with DDL.
There are obvious workarounds. One could use a trigger and a foreign
key.
But my questions are:
1. Is there enough use in something like this to even try to tackle
it?
2. Are there any other major showstoppers I haven't thought of?
Purely from a user perspective IMO it seems like a good idea and a
logical progression from index expressions. You could even make use
of the equivalent index expression if it existed, or (better) insist
on it, because the calculated value would have to be UNIQUE anyway
(otherwise you end up in all sorts of trouble).
Wouldn't the ability to have virtual columns (aka computed or generated
columns) inside a table be a generalization of this?
The feature would need some kind of "virtual column" to support the FKs anyway,
if I'm not mistaken (because the FK value needs to be stored somewhere in order to be
able to look it up).
So I think exposing the ability to declare a virtual column would open up even
more possibilities (and then in turn allow those virtual columns to be used in
a FK constraint).
Thomas
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
