Chris Travers <chris.travers@gmail.com> writes:
> On Thu, Feb 7, 2013 at 7:04 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Chris Travers <chris.travers@gmail.com> writes:
>>> What would be nice to be able to do is to be able to do something like:
>>> ALTER TABLE inet_assignment ADD FOREIGN KEY (network(inet_address))
>>> REFERENCES cidr_block(block_def);
>>>
>>> 2. Are there any other major showstoppers I haven't thought of?
>> The information_schema can't represent such a thing, and this is
>> unfixable without breaking the SQL standard. I suppose we could omit
>> functional FK constraints from the information_schema views, but that's
>> not terribly palatable.
> If this were to be limited to table methods (i.e. functions where
> relation.function notation works), would that be sufficiently workable?
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. But it would sure violate some other parts.
For instance an app would expect to be able to join that column to
information_schema.columns. On the whole I doubt that it's really a
good idea to break spec compatibility subtly rather than obviously.
regards, tom lane
