On Mon, Aug 24, 2015 at 5:15 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Alexander Korotkov <a.korotkov@postgrespro.ru> writes: > On Mon, Aug 10, 2015 at 7:50 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Hm. So one way or the other we're going to end up violating relational >> theory somewhere. OK, I yield: let's say that pg_am has amname, amkind, >> amhandler, and nothing else. Then we will need SQL functions to expose >> whatever information we think needs to be available to SQL code.
> There is second revision of this patch. Changes are so:
> * AmRoutine was renamed to IndexAmRoutine assuming there could be other > access methods in the future. > * amhandlers now return index_am_handler pseudotype. > * CHECK_PROCEDUREs are now is the place of original GET_REL_PROCEDUREs. > * amstrategies, amsupport, amcanorderbyop, amstorage, amkeytype are in > both pg_am and IndexAmRoutine. Consistence of amhandler answer and pg_am > tuple is checking.
[ scratches head... ] I thought we'd just agreed we weren't going to keep any of those pg_am columns? If we keep them, we'll have to define what they mean for sequence AMs etc. ("Let them be NULL" would likely break enough stuff that we might as well not have them.)
From the previous discussion I see following options:
1) Non-index access methods don't reuse pg_class.relam nor pg_am. Fully relational compliant but complex catalog structure.
2) Non-index access methods reuse pg_class.relam but don't reuse pg_am. This violates relational theory because single column reference multiple tables.
3) Non-index access methods reuse both pg_class.relam and pg_am. This violates relational theory because we store different objects in the same table.
I'd say we already have precedent of #2. It's pg_depend which reference objects of arbitrary types.
In the #3 we really shouldn't keep any specific to index am in pg_am.
But what we assume to be an access method in general? For instance, we have foreign data wrappers which aren't access methods (but looks quite similar from some degree).
