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