| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Petr Jelinek <petr(at)2ndquadrant(dot)com> |
| Cc: | Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Robert Haas <robertmhaas(at)gmail(dot)com> |
| Subject: | Re: WIP: Rework access method interface |
| Date: | 2015-08-10 15:47:00 |
| Message-ID: | 15580.1439221620@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Petr Jelinek <petr(at)2ndquadrant(dot)com> writes:
> On 2015-08-10 16:58, Alexander Korotkov wrote:
>> That should work, thanks! Also we can have SQL-visible functions to get
>> amsupport and amstrategies and use them in the regression tests.
> SQL-visible functions would be preferable to storing it in pg_am as
> keeping the params in pg_am would limit the extensibility of pg_am itself.
I don't see any particularly good reason to remove amsupport and
amstrategies from pg_am. Those are closely tied to the other catalog
infrastructure for indexes (pg_amproc, pg_amop) which I don't think are
candidates for getting changed by this patch.
There are a couple of other pg_am columns, such as amstorage and
amcanorderbyop, which similarly bear on what's legal to appear in
related catalogs such as pg_opclass. I'd be sort of inclined to
leave those in the catalog as well. I do not see that exposing
a SQL function is better than exposing a catalog column; either
way, that property is SQL-visible.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alexander Korotkov | 2015-08-10 15:53:27 | Re: WIP: Rework access method interface |
| Previous Message | Alexander Korotkov | 2015-08-10 15:41:33 | Re: WIP: Rework access method interface |