Re: TABLESAMPLE patch is really in pretty sad shape

On 2015-07-16 17:08, Tom Lane wrote:
> Petr Jelinek <petr(at)2ndquadrant(dot)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.)
>

Well not necessarily, it would just mean that relam has different
meaning depending on relkind so the OID uniqueness is not needed at all.

> 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.
>

Yes, this would be better.

--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services