Re: Re: feature requests (possibly interested in working on this): functional foreign keys

On 7 February 2013 11:18, Thomas Kellerer <spam_eater(at)gmx(dot)net> wrote:

> Geoff Winkless, 07.02.2013 11:46:
>
>> On 7 February 2013 09:38, Chris Travers <chris(dot)travers(at)gmail(dot)com
>> <mailto:chris(dot)travers(at)gmail(dot)**com <chris(dot)travers(at)gmail(dot)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