From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Amit Langote <amitlangote09(at)gmail(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Petr Jelinek <petr(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: TABLESAMPLE patch is really in pretty sad shape |
Date: | 2015-07-16 14:16:20 |
Message-ID: | 3484.1437056180@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Amit Langote <amitlangote09(at)gmail(dot)com> writes:
> On Thu, Jul 16, 2015 at 10:33 PM, Alvaro Herrera
> <alvherre(at)2ndquadrant(dot)com> wrote:
>> Hmm, how would this work? Would we have index AM implementation run
>> some function that register their support methods somehow at startup?
> I recall a proposal by Alexander Korotkov about extensible access
> methods although his proposal also included a CREATE AM command that
> would add a pg_am row so that perhaps differs from what Tom seems to
> allude to here.
I think we'd still need to invent CREATE AM if we wanted to allow index
AMs to be created as extensions; we'd still have to have the pg_am
catalog, and extensions still couldn't write rows directly into that,
for the same reasons I pointed out with respect to tablesample methods.
However, if the contents of pg_am could be boiled down to just a name and
a handler function, then that would represent a simple and completely
stable definition for CREATE AM's arguments, which would be a large
improvement over trying to reflect the current contents of pg_am directly
in a SQL statement. We add new columns to pg_am all the time, and that
would create huge backward-compatibility headaches if we had to modify
the behavior of a CREATE AM statement every time.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2015-07-16 14:22:08 | Re: TABLESAMPLE doesn't actually satisfy the SQL spec, does it? |
Previous Message | Amit Langote | 2015-07-16 14:16:07 | Re: [PATCH] postgres_fdw extension support |