On Mon, Aug 24, 2015 at 5:15 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Alexander Korotkov <a.korot...@postgrespro.ru> writes:
> > On Mon, Aug 10, 2015 at 7:50 PM, Tom Lane <t...@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).
------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
