Petr Jelinek <petr@2ndquadrant.com> writes:
> On 2015-07-16 15:59, Tom Lane wrote:
>> I'm not clear on whether sequence AMs would need explicit catalog
>> representation, or could be folded down to just a single SQL function
>> with special signature as I suggested for tablesample handlers.
>> Is there any need for a sequence AM to have additional catalog
>> infrastructure like index AMs need?
> That depends on the route we will choose to take with the storage there.
> If we allow custom columns for sequence AMs (which is what both Heikki
> and me seem to be inclined to do) then I think it will still need
> catalog, plus it's also easier to just reuse the relam behavior than
> coming up up with something completely new IMHO.
Hm. I've not been following the sequence AM stuff carefully, but if you
want to use relam to point at a sequence's AM then really sequence AMs
have to be represented in pg_am. (It would be quite broken from a
relational theory standpoint if relam could point to either of two
catalogs; not to mention that we have no way to guarantee OID uniqueness
across multiple catalogs.)
As things stand today, putting both kinds of AM into one catalog would be
pretty horrible, but it seems not hard to make it work if we did this sort
of refactoring first. We'd end up with three columns in pg_am: amname,
amkind (index or sequence), and amhandler. The type and contents of the
struct returned by amhandler could be different depending on amkind, which
means that the APIs could be as different as we need, despite sharing just
one catalog. The only real restriction is that index and sequence AMs
could not have the same names, which doesn't seem like much of a problem
from here.
regards, tom lane
