Chris Travers <chris.travers@xxxxxxxxx> writes: > On Thu, Feb 7, 2013 at 7:04 AM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: >> Chris Travers <chris.travers@xxxxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
