Re: WIP: Rework access method interface

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