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
