On Thu, Feb 7, 2013 at 9:59 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Geoff Winkless <pgsqlgeneral@geoff.dj> writes:
> > On 7 February 2013 16:26, Tom Lane <tgl@sss.pgh.pa.us> 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?
>
> My point is that the spec expects that identifier to be the name of a
> 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@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>