Re: TABLESAMPLE patch is really in pretty sad shape
От | Tom Lane |
---|---|
Тема | Re: TABLESAMPLE patch is really in pretty sad shape |
Дата | |
Msg-id | 3484.1437056180@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: TABLESAMPLE patch is really in pretty sad shape (Amit Langote <amitlangote09@gmail.com>) |
Список | pgsql-hackers |
Amit Langote <amitlangote09@gmail.com> writes: > On Thu, Jul 16, 2015 at 10:33 PM, Alvaro Herrera > <alvherre@2ndquadrant.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
В списке pgsql-hackers по дате отправления: