On 8/25/15 10:56 AM, Tom Lane wrote:
I'm good with this as long as all the things that get stored in pg_am are things that pg_class.relam can legitimately reference. If somebody proposed adding an "access method" kind that was not a relation access method, I'd probably push back on whether that should be in pg_am or someplace else.
Would fields in pg_am be overloaded then? From a SQL standpoint it'd be much nicer to have child tables, though that could potentially be faked with views.
The fact that the subsidiary tables like pg_opclass no longer have perfectly clean foreign keys to pg_am is a bit annoying, but that's better than having pg_class.relam linking to multiple tables. (Also, if we really wanted to we could define the foreign key constraints as multicolumn ones that also require a match on amkind. So it's not*that* broken. We could easily add opr_sanity tests to verify proper matching.)
I have wished for something similar to CHECK constraints that operated on data in a *related* table (something we already have a foreign key to) for this purpose. In the past I've enforced it with triggers on both sides but writing those gets old after a while.
-- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
