On 7 February 2013 11:18, Thomas Kellerer <spam_eater@gmx.net> wrote:
> Geoff Winkless, 07.02.2013 11:46:
>
>> On 7 February 2013 09:38, Chris Travers <chris.travers@gmail.com
>> <mailto:chris.travers@gmail.**com <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
