On Thu, Feb 7, 2013 at 9:59 AM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote:
My point is that the spec expects that identifier to be the name of aGeoff Winkless <pgsqlgeneral@xxxxxxxx> writes:
> On 7 February 2013 16:26, Tom Lane <tgl@xxxxxxxxxxxxx> wrote:
>> Hmm, interesting hack. I guess that would meet the part of the spec
>> that says, eg, information_schema.constraint_column_usage.column_name
>> must be an identifier --- at least if you also restricted which schema
>> the function could be in.
> Apologies if I'm misunderstanding your point; couldn't you give the index
> name (since we've suggested you would have to have a unique index on the
> function in order to use it as an FK anyway) as the identifier?
column in the table, and so will spec-compliant applications. Inventing
different ways to provide an identifier that can be claimed to describe
the functional _expression_ doesn't really do anything to get around that
problem.
I'm inclined to think that the way that the standards committee expects
people to get around this is to store the functional _expression_
explicitly as a separate column. There's a feature called "generated
columns" in recent versions of the spec that automates that. PG hasn't
implemented generated columns yet, but you can get the same effect with
a BEFORE trigger to calculate the separate column's value.
Thanks. That's the sort of show-stopper that was overlooking.
It seems that to make the table method approach work we'd have to be able to have some other things in place first, perhaps being able to explicitly define a table method as a "virtual column" that could be seen in the information schema (and possibly making the args of the function entirely implicit, allowing select method from relation.
That might be worthwhile too but it significantly expands the scope of what I was looking at.
Best Wishes,
Chris Travers
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
