WIP: Rework access method interface
Hacker,
some time before I proposed patches implementing CREATE ACCESS METHOD.
/messages/by-id/CAPpHfdsXwZmojm6Dx+TJnpYk27kT4o7Ri6X_4OSWcByu1Rm+VA@mail.gmail.com
As I get from comments to my patches and also from Tom's comment about AM
interface in tablesampling thread – AM interface needs reworking. And
AFAICS AM interface rework is essential to have CREATE ACCESS METHOD
command.
/messages/by-id/5438.1436740611@sss.pgh.pa.us
This is why I'd like to show a WIP patch implementing AM interface rework.
Patch is quite dirty yet, but I think it illustrated the idea quite clear.
AM now have single parameter – handler function. This handler returns
pointer to AmRoutine which have the same data as pg_am had before. Thus,
API is organized very like FDW.
However, this patch appears to take more work than I expected. It have to
do many changes spread among many files. Also, it appears not so easy to
hide amsupport into AmRoutine, because it's needed for relcache. As a
temporary solution it's duplicated in RelationData.
What do you think about this approach of AM interface rework?
------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Attachments:
aminterface-1.patchapplication/octet-stream; name=aminterface-1.patchDownload+1657-1685
On 2015-08-09 23:56, Alexander Korotkov wrote:
Hacker,
some time before I proposed patches implementing CREATE ACCESS METHOD.
/messages/by-id/CAPpHfdsXwZmojm6Dx+TJnpYk27kT4o7Ri6X_4OSWcByu1Rm+VA@mail.gmail.com
As I get from comments to my patches and also from Tom's comment about
AM interface in tablesampling thread – AM interface needs reworking. And
AFAICS AM interface rework is essential to have CREATE ACCESS METHOD
command.
/messages/by-id/5438.1436740611@sss.pgh.pa.us
Cool, I was planning to take a stab at this myself when I have time, so
I am glad you posted this.
This is why I'd like to show a WIP patch implementing AM interface
rework. Patch is quite dirty yet, but I think it illustrated the idea
quite clear. AM now have single parameter – handler function. This
handler returns pointer to AmRoutine which have the same data as pg_am
had before. Thus, API is organized very like FDW.
I wonder if it would make sense to call it IndexAmRoutine instead in
case we add other AMs (like the sequence am, or maybe column store if
that's done as AM) in the future.
The patch should probably add the am_handler type which should be return
type of the am handler function (see fdw_handler and tsm_handler types).
I also think that the CHECK_PROCEDUREs should be in the place of the
original GET_REL_PROCEDUREs (just after relation check). If the
interface must exist we may as well check for it at the beginning and
not after we did some other work which is useless without the interface.
However, this patch appears to take more work than I expected. It have
to do many changes spread among many files.
Yeah you need to change the definition and I/O handling of every AM
function, but that's to be expected.
Also, it appears not so easy
to hide amsupport into AmRoutine, because it's needed for relcache. As a
temporary solution it's duplicated in RelationData.
I don't understand this, there is already AmRoutine in RelationData, why
the need for additional field for just amsupport?
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Aug 10, 2015 at 1:12 PM, Petr Jelinek <petr@2ndquadrant.com> wrote:
On 2015-08-09 23:56, Alexander Korotkov wrote:
Hacker,
some time before I proposed patches implementing CREATE ACCESS METHOD.
/messages/by-id/CAPpHfdsXwZmojm6Dx+TJnpYk27kT4o7Ri6X_4OSWcByu1Rm+VA@mail.gmail.com
As I get from comments to my patches and also from Tom's comment about
AM interface in tablesampling thread – AM interface needs reworking. And
AFAICS AM interface rework is essential to have CREATE ACCESS METHOD
command.
/messages/by-id/5438.1436740611@sss.pgh.pa.usCool, I was planning to take a stab at this myself when I have time, so I
am glad you posted this.This is why I'd like to show a WIP patch implementing AM interface
rework. Patch is quite dirty yet, but I think it illustrated the idea
quite clear. AM now have single parameter – handler function. This
handler returns pointer to AmRoutine which have the same data as pg_am
had before. Thus, API is organized very like FDW.I wonder if it would make sense to call it IndexAmRoutine instead in case
we add other AMs (like the sequence am, or maybe column store if that's
done as AM) in the future.
Good point!
The patch should probably add the am_handler type which should be return
type of the am handler function (see fdw_handler and tsm_handler types).
Sounds reasonable!
I also think that the CHECK_PROCEDUREs should be in the place of the
original GET_REL_PROCEDUREs (just after relation check). If the interface
must exist we may as well check for it at the beginning and not after we
did some other work which is useless without the interface.
Ok, good point too.
However, this patch appears to take more work than I expected. It have
to do many changes spread among many files.
Yeah you need to change the definition and I/O handling of every AM
function, but that's to be expected.
Yes, this is why I decided to get some feedback on this stage of work.
Also, it appears not so easy
to hide amsupport into AmRoutine, because it's needed for relcache. As a
temporary solution it's duplicated in RelationData.I don't understand this, there is already AmRoutine in RelationData, why
the need for additional field for just amsupport?
We need amsupport in load_relcache_init_file() which reads
"pg_internal.init". I'm not sure this is correct place to call am_handler.
It should work in the case of built-in AM. But if AM is defined in the
extension then we wouldn't be able to do catalog lookup for am_handler on
this stage of initialization.
Another point is that amsupport and amstrategies are used for regression
tests of opclasses and opfamilies. Thus, we probably can keep them in pg_am.
------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Alexander Korotkov <a.korotkov@postgrespro.ru> writes:
On Mon, Aug 10, 2015 at 1:12 PM, Petr Jelinek <petr@2ndquadrant.com> wrote:
I don't understand this, there is already AmRoutine in RelationData, why
the need for additional field for just amsupport?
We need amsupport in load_relcache_init_file() which reads
"pg_internal.init". I'm not sure this is correct place to call am_handler.
It should work in the case of built-in AM. But if AM is defined in the
extension then we wouldn't be able to do catalog lookup for am_handler on
this stage of initialization.
This is an issue we'll have to face before there's much hope of having
index AMs as extensions: how would you locate any extension function
without catalog access? Storing raw function pointers in pg_internal.init
is not an answer in an ASLR world.
I think we can dodge the issue so far as pg_internal.init is concerned by
decreeing that system catalogs can only have indexes with built-in AMs.
Calling a built-in function doesn't require catalog access, so there
should be no problem with re-calling the handler function by OID during
load_relcache_init_file().
We could also have problems with WAL replay, though I think the consensus
there is that extension AMs have to use generic WAL records that don't
require any index-specific replay code.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Aug 10, 2015 at 5:48 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Alexander Korotkov <a.korotkov@postgrespro.ru> writes:
On Mon, Aug 10, 2015 at 1:12 PM, Petr Jelinek <petr@2ndquadrant.com>
wrote:
I don't understand this, there is already AmRoutine in RelationData, why
the need for additional field for just amsupport?We need amsupport in load_relcache_init_file() which reads
"pg_internal.init". I'm not sure this is correct place to callam_handler.
It should work in the case of built-in AM. But if AM is defined in the
extension then we wouldn't be able to do catalog lookup for am_handler on
this stage of initialization.This is an issue we'll have to face before there's much hope of having
index AMs as extensions: how would you locate any extension function
without catalog access? Storing raw function pointers in pg_internal.init
is not an answer in an ASLR world.I think we can dodge the issue so far as pg_internal.init is concerned by
decreeing that system catalogs can only have indexes with built-in AMs.
Calling a built-in function doesn't require catalog access, so there
should be no problem with re-calling the handler function by OID during
load_relcache_init_file().
That should work, thanks! Also we can have SQL-visible functions to get
amsupport and amstrategies and use them in the regression tests.
We could also have problems with WAL replay, though I think the consensus
there is that extension AMs have to use generic WAL records that don't
require any index-specific replay code.
Yes, I've already showed one version of generic WAL records. The main
objecting against them was it's hard insure that composed WAL-record is
correct.
Now I'm working on new version which would be much easier and safe to use.
------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On 2015-08-10 16:58, Alexander Korotkov wrote:
On Mon, Aug 10, 2015 at 5:48 PM, Tom Lane <tgl@sss.pgh.pa.us
<mailto:tgl@sss.pgh.pa.us>> wrote:Alexander Korotkov <a.korotkov@postgrespro.ru
<mailto:a.korotkov@postgrespro.ru>> writes:On Mon, Aug 10, 2015 at 1:12 PM, Petr Jelinek <petr@2ndquadrant.com <mailto:petr@2ndquadrant.com>> wrote:
I don't understand this, there is already AmRoutine in RelationData, why
the need for additional field for just amsupport?We need amsupport in load_relcache_init_file() which reads
"pg_internal.init". I'm not sure this is correct place to call am_handler.
It should work in the case of built-in AM. But if AM is defined in the
extension then we wouldn't be able to do catalog lookup for am_handler on
this stage of initialization.This is an issue we'll have to face before there's much hope of having
index AMs as extensions: how would you locate any extension function
without catalog access? Storing raw function pointers in
pg_internal.init
is not an answer in an ASLR world.I think we can dodge the issue so far as pg_internal.init is
concerned by
decreeing that system catalogs can only have indexes with built-in AMs.
Calling a built-in function doesn't require catalog access, so there
should be no problem with re-calling the handler function by OID during
load_relcache_init_file().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.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Aug 10, 2015 at 6:36 PM, Petr Jelinek <petr@2ndquadrant.com> wrote:
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 actually meant just two particular functions (not per AM) which both get
AM oid as argument. They should call amhandler and return amsupport and
amstrategies correspondingly.
These functions can be used in regression tests to check opclass and
opfamilies correctness.
------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Petr Jelinek <petr@2ndquadrant.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Aug 10, 2015 at 6:47 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Petr Jelinek <petr@2ndquadrant.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_amitself.
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.
That answers my question, thanks!
------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On 2015-08-10 17:47, Tom Lane wrote:
Petr Jelinek <petr@2ndquadrant.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.
Ok, in that case it seems unlikely that we'll be able to use pg_am for
any other access methods besides indexes in the future.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Alexander Korotkov <a.korotkov@postgrespro.ru> writes:
On Mon, Aug 10, 2015 at 6:47 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
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.
That answers my question, thanks!
BTW, just to clarify: we can still have the desirable property that
CREATE INDEX ACCESS METHOD needs no parameters other than the AM handler
function name. The AM code would still expose all of its properties
through the struct returned by the handler. What is at issue here is
how information in that struct that needs to be available to SQL code
gets exposed. We can do that either by exposing SQL functions to get
it, or by having CREATE INDEX ACCESS METHOD call the handler and then
copy some fields into the new pg_am row. I'm suggesting that we should
do the latter for any fields that determine validity of pg_opclass,
pg_amop, etc entries associated with the AM type. The AM could not
reasonably change its mind about such properties (within a major
release at least) so there is no harm in making a long-lived copy
in pg_am. And we might as well not break SQL code unnecessarily
by removing fields that used to be there.
There may be some other AM properties that would be better to expose
through SQL functions because they could potentially change without
invalidating information stored in the other catalogs. I'm not sure
whether there is any such data that needs to be accessible at SQL
level, though.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Petr Jelinek <petr@2ndquadrant.com> writes:
On 2015-08-10 17:47, Tom Lane wrote:
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.
Ok, in that case it seems unlikely that we'll be able to use pg_am for
any other access methods besides indexes in the future.
I think that's likely for the best anyway; there are too many catalogs
that think a pg_am OID identifies an index AM. Better to create other
catalogs for other types of AMs.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Tom Lane wrote:
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.
If we do that, it doesn't seem reasonable to use the same catalog for
other things such as sequence AM, right? IMO it'd be better to keep the
catalog agnostic for exactly what each row is going to be an AM for.
--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2015-08-10 18:08, Tom Lane wrote:
Alexander Korotkov <a.korotkov@postgrespro.ru> writes:
On Mon, Aug 10, 2015 at 6:47 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
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.That answers my question, thanks!
BTW, just to clarify: we can still have the desirable property that
CREATE INDEX ACCESS METHOD needs no parameters other than the AM handler
function name. The AM code would still expose all of its properties
through the struct returned by the handler. What is at issue here is
how information in that struct that needs to be available to SQL code
gets exposed. We can do that either by exposing SQL functions to get
it, or by having CREATE INDEX ACCESS METHOD call the handler and then
copy some fields into the new pg_am row. I'm suggesting that we should
do the latter for any fields that determine validity of pg_opclass,
pg_amop, etc entries associated with the AM type. The AM could not
reasonably change its mind about such properties (within a major
release at least) so there is no harm in making a long-lived copy
in pg_am. And we might as well not break SQL code unnecessarily
by removing fields that used to be there.
That's definitely the case for built-in AMs but 3rd party ones won't
necessarily follow PG release schedule/versioning and I can imagine
change of for example amcanorderbyop between AM releases as the AM
matures. This could probably be solved by some kind of invalidation
mechanism (even if it's some additional SQL).
However I am not sure if using catalog as some sort of cache for
function output is a good idea in general. IMHO it would be better to
just have those options as part of CREATE and ALTER DDL for INDEX ACCESS
METHODS if we store them in pg_am.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2015-08-10 18:16, Alvaro Herrera wrote:
Tom Lane wrote:
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.If we do that, it doesn't seem reasonable to use the same catalog for
other things such as sequence AM, right? IMO it'd be better to keep the
catalog agnostic for exactly what each row is going to be an AM for.
Yeah I said the same, the question is if we should have pg_am agnostic
or just assume that it's index AM and let other AM types create separate
catalogs. Tom seems to prefer the latter, I don't see problem with that,
except that I would really hate to add more am related columns to
pg_class. I would not mind having relam pointing to different AM catalog
for different relkinds but dunno if that's ok for others (it's not
really normalized design).
We could also keep pg_am agnostic and add pg_index_am for additional
info about index AMs, but that would make this patch more invasive.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Tom Lane wrote:
Petr Jelinek <petr@2ndquadrant.com> writes:
On 2015-08-10 17:47, Tom Lane wrote:
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.Ok, in that case it seems unlikely that we'll be able to use pg_am for
any other access methods besides indexes in the future.I think that's likely for the best anyway; there are too many catalogs
that think a pg_am OID identifies an index AM. Better to create other
catalogs for other types of AMs.
That means we won't be able to reuse pg_class.relam as a pointer to the
AM-of-the-other-kind either. I don't think this is the best course of
action. We have the sequence AM patch that already reuses
pg_class.relam to point to pg_seqam.oid, but you objected to that on
relational theory grounds, which seemed reasonable to me. The other
option is to create yet another pg_class column with an OID of some
other AM catalog, but this seems a waste.
FWIW the column store patch we're working on also wants to have its own
AM-like catalog. In our current code we have a separate catalog
pg_colstore_am, but are eagerly waiting for the discussion on this to
settle so that we can just use pg_am and pg_class.relam instead. (The
patch itself is not public yet since it's nowhere near usable, and this
detail is a pretty minor issue, but I thought reasonable to bring it up
here. We're also waiting on upper-planner "path-ification" since it
seems likely that some code will collide there, anyway.)
--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
Tom Lane wrote:
I think that's likely for the best anyway; there are too many catalogs
that think a pg_am OID identifies an index AM. Better to create other
catalogs for other types of AMs.
That means we won't be able to reuse pg_class.relam as a pointer to the
AM-of-the-other-kind either.
Hm. So one way or the other we're going to end up violating relational
theory somewhere. OK, I yield: let's say that pg_am has amname, amkind,
amhandler, and nothing else. Then we will need SQL functions to expose
whatever information we think needs to be available to SQL code.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Aug 10, 2015 at 7:50 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
Tom Lane wrote:
I think that's likely for the best anyway; there are too many catalogs
that think a pg_am OID identifies an index AM. Better to create other
catalogs for other types of AMs.That means we won't be able to reuse pg_class.relam as a pointer to the
AM-of-the-other-kind either.Hm. So one way or the other we're going to end up violating relational
theory somewhere. OK, I yield: let's say that pg_am has amname, amkind,
amhandler, and nothing else. Then we will need SQL functions to expose
whatever information we think needs to be available to SQL code.
There is second revision of this patch. Changes are so:
* AmRoutine was renamed to IndexAmRoutine assuming there could be other
access methods in the future.
* amhandlers now return index_am_handler pseudotype.
* CHECK_PROCEDUREs are now is the place of original GET_REL_PROCEDUREs.
* amstrategies, amsupport, amcanorderbyop, amstorage, amkeytype are in
both pg_am and IndexAmRoutine. Consistence of amhandler answer and pg_am
tuple is checking.
* Some comments and refactoring.
------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Attachments:
aminterface-2.pathapplication/octet-stream; name=aminterface-2.pathDownload+1709-1884
Alexander Korotkov <a.korotkov@postgrespro.ru> writes:
On Mon, Aug 10, 2015 at 7:50 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Hm. So one way or the other we're going to end up violating relational
theory somewhere. OK, I yield: let's say that pg_am has amname, amkind,
amhandler, and nothing else. Then we will need SQL functions to expose
whatever information we think needs to be available to SQL code.
There is second revision of this patch. Changes are so:
* AmRoutine was renamed to IndexAmRoutine assuming there could be other
access methods in the future.
* amhandlers now return index_am_handler pseudotype.
* CHECK_PROCEDUREs are now is the place of original GET_REL_PROCEDUREs.
* amstrategies, amsupport, amcanorderbyop, amstorage, amkeytype are in
both pg_am and IndexAmRoutine. Consistence of amhandler answer and pg_am
tuple is checking.
[ scratches head... ] I thought we'd just agreed we weren't going to keep
any of those pg_am columns? If we keep them, we'll have to define what
they mean for sequence AMs etc. ("Let them be NULL" would likely break
enough stuff that we might as well not have them.)
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Aug 24, 2015 at 5:15 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Alexander Korotkov <a.korotkov@postgrespro.ru> writes:
On Mon, Aug 10, 2015 at 7:50 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Hm. So one way or the other we're going to end up violating relational
theory somewhere. OK, I yield: let's say that pg_am has amname, amkind,
amhandler, and nothing else. Then we will need SQL functions to expose
whatever information we think needs to be available to SQL code.There is second revision of this patch. Changes are so:
* AmRoutine was renamed to IndexAmRoutine assuming there could be other
access methods in the future.
* amhandlers now return index_am_handler pseudotype.
* CHECK_PROCEDUREs are now is the place of original GET_REL_PROCEDUREs.
* amstrategies, amsupport, amcanorderbyop, amstorage, amkeytype are in
both pg_am and IndexAmRoutine. Consistence of amhandler answer and pg_am
tuple is checking.[ scratches head... ] I thought we'd just agreed we weren't going to keep
any of those pg_am columns? If we keep them, we'll have to define what
they mean for sequence AMs etc. ("Let them be NULL" would likely break
enough stuff that we might as well not have them.)
From the previous discussion I see following options:
1) Non-index access methods don't reuse pg_class.relam nor pg_am. Fully
relational compliant but complex catalog structure.
2) Non-index access methods reuse pg_class.relam but don't reuse pg_am.
This violates relational theory because single column reference multiple
tables.
3) Non-index access methods reuse both pg_class.relam and pg_am. This
violates relational theory because we store different objects in the same
table.
I'd say we already have precedent of #2. It's pg_depend which reference
objects of arbitrary types.
In the #3 we really shouldn't keep any specific to index am in pg_am.
But what we assume to be an access method in general? For instance, we have
foreign data wrappers which aren't access methods (but looks quite similar
from some degree).
------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
