On 7 February 2013 11:18, Thomas Kellerer <spam_eater@xxxxxxx> wrote:
Geoff Winkless, 07.02.2013 11:46:On 7 February 2013 09:38, Chris Travers <chris.travers@xxxxxxxxx
<mailto:chris.travers@gmail.com>> wrote:
1: The foreign key depends on the function so the function cannot be
dropped first absent CASCADE
[snip]
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).
Please note that the indenting is messed up here; I did not write the first section of this, Chris did; only the last paragraph is mine.
Wouldn't the ability to have virtual columns (aka computed or generated columns) inside a table be a generalization of this?
Well it would be a much larger block of work with a much heavier impact and (IMO) the value of taking up disk space with a column that is based on (and entirely generate-able from) other columns is dubious. I imagine similar arguments took place when _expression_ indexes were mooted.
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).
Which is resolved by relying on the _expression_ index.
Geoff
