Re: [HACKERS] WIP: Rework access method interface

On Sat, Jan 16, 2016 at 12:32 PM, Tom Lane wrote: > Then we're going to end up with option A; and I suspect that we'll never > bother with factoring out any common code, because it won't be worth the > notational trouble if it involves common code that's in a different file >

Re: [HACKERS] WIP: Rework access method interface

Alexander Korotkov writes: > [ aminterface-13.patch ] I've committed this after some rather significant rework, not all of it cosmetic in nature. For example, the patch fell over under CLOBBER_CACHE_ALWAYS (planner failing to copy data out of relcache entries that

Re: [HACKERS] WIP: Rework access method interface

Amit Kapila writes: > Shouldn't we try to move amhandler function as well along with > amvalidate? I think moving each am's handler and validate into > am specific new file can make this arrangement closer to what > we have for PL's (ex. we have plpgsql_validator and

Re: [HACKERS] WIP: Rework access method interface

On Sat, Jan 16, 2016 at 9:43 PM, Tom Lane wrote: > > Alexander Korotkov writes: > > [ aminterface-13.patch ] > > I've started to review this. There are a bunch of cosmetic things I don't > like, notably the include-file nesting you've chosen, but

Re: [HACKERS] WIP: Rework access method interface

On January 16, 2016 6:32:47 PM GMT+01:00, Tom Lane wrote: >As for modularity, nobody's moaned particularly about the >amcostestimate >functions all being in selfuncs.c. It all depends on what you think is >"modular". Well, back then you couldn't really have a production

Re: [HACKERS] WIP: Rework access method interface

On Jan 16, 2016, at 11:13 AM, Tom Lane wrote: > Alexander Korotkov writes: >> [ aminterface-13.patch ] > > I've started to review this. There are a bunch of cosmetic things I don't > like, notably the include-file nesting you've chosen, but

Re: [HACKERS] WIP: Rework access method interface

Robert Haas writes: > On Jan 16, 2016, at 11:13 AM, Tom Lane wrote: >> There are a couple of things we could do instead: >> >> * Put each amvalidate function into its own file (but probably keep it >> in the same directory as now). This is a

Re: [HACKERS] WIP: Rework access method interface

Alexander Korotkov writes: > [ aminterface-13.patch ] I've started to review this. There are a bunch of cosmetic things I don't like, notably the include-file nesting you've chosen, but they're fixable. One item that I think could use some discussion is where to put

Re: [HACKERS] WIP: Rework access method interface

Alvaro Herrera writes: > I just noticed that this patch had remained in Waiting-for-author status > after Alexander had already submitted the updated version of the patch. > I marked it as ready-for-committer, because Petr stated so in the > thread. > Tom, you're

Re: [HACKERS] WIP: Rework access method interface

I just noticed that this patch had remained in Waiting-for-author status after Alexander had already submitted the updated version of the patch. I marked it as ready-for-committer, because Petr stated so in the thread. Tom, you're registered as committer for this patch. Do you have time in the

Re: [HACKERS] WIP: Rework access method interface

On 2015-12-24 14:57, Alexander Korotkov wrote: What do you think about ​"​ System Administration Functions ​" chapter? http://www.postgresql.org/docs/devel/static/functions-admin.html Other than that I am happy with the patch. Sounds good to me. One last tiny gripe, I think the

Re: [HACKERS] WIP: Rework access method interface

On Mon, Dec 14, 2015 at 11:26 PM, Petr Jelinek wrote: > These look like copy-pastos of boilerplate. > > Another note is that amvalidate SQL interface is not documented anywhere. I > know it's mainly meant for regression tests and we for example don't > document hashing

Re: [HACKERS] WIP: Rework access method interface

On 2015-12-12 23:17, Alexander Korotkov wrote: On Sat, Dec 12, 2015 at 9:21 PM, Petr Jelinek > wrote: On 2015-12-09 15:09, Alexander Korotkov wrote: ​Patch was rebased against current master. Any notes about current

Re: [HACKERS] WIP: Rework access method interface

On 2015-12-09 15:09, Alexander Korotkov wrote: ​Patch was rebased against current master. Any notes about current version of patch? It would be nice to commit it and continue work on other parts of am extendability.​ The rebase seems broken, there are things missing in this version of the

Re: [HACKERS] WIP: Rework access method interface

On Tue, Nov 3, 2015 at 2:36 AM, Tom Lane wrote: > Alvaro Herrera writes: > > Tom Lane wrote: > >> I'm kind of inclined to just let the verifiers read the catalogs for > >> themselves. AFAICS, a loop around the results of SearchSysCacheList > >> is

Re: [HACKERS] WIP: Rework access method interface

Tom Lane wrote: > Probably the least messy way to fix this is to drop that #include and > instead use dummy declarations like "struct PlannerInfo;" and "struct > IndexPath;" here. We could additionally dumb the amcostestimate > declaration down from using "Cost" and "Selectivity" to just saying

Re: [HACKERS] WIP: Rework access method interface

Tom Lane wrote: > I follow your reasoning, but I don't particularly want to make this > patch wait on a large and invasive refactoring of existing headers. Sure. > As a down payment on this problem, maybe we could invent a new planner > header that provides just enough info to support amapi.h

Re: [HACKERS] WIP: Rework access method interface

Alvaro Herrera writes: > Tom Lane wrote: >> As a down payment on this problem, maybe we could invent a new planner >> header that provides just enough info to support amapi.h and fdwapi.h; >> it looks like this would be "typedef struct PlannerInfo PlannerInfo;", >>

Re: [HACKERS] WIP: Rework access method interface

On 2015-11-02 23:28, Tom Lane wrote: Alvaro Herrera writes: Tom Lane wrote: Regardless of that, I'm a bit skeptical that any of these structs ought to be defined as part of the amapi.h interface. They seem to be making premature judgments as to what an opclass

Re: [HACKERS] WIP: Rework access method interface

Alexander Korotkov writes: > Tom, could you take a look at them? I started to look at this today. (Apologies for the delay, but I came back from San Francisco with a nasty head cold, and wasn't really up to doing anything complicated last week.) The thing that jumps

Re: [HACKERS] WIP: Rework access method interface

Alvaro Herrera writes: > Tom Lane wrote: >> Probably the least messy way to fix this is to drop that #include and >> instead use dummy declarations like "struct PlannerInfo;" and "struct >> IndexPath;" here. We could additionally dumb the amcostestimate >> declaration

Re: [HACKERS] WIP: Rework access method interface

Alvaro Herrera writes: > Tom Lane wrote: >> ... btw, what is the point of catalog/opfam_internal.h? I see you added >> it in b488c580aef4e05f, but it seems quite useless to have split it out >> as a separate header, since only commands/opclasscmds.c uses it. > Oh, that

Re: [HACKERS] WIP: Rework access method interface

... btw, what is the point of catalog/opfam_internal.h? I see you added it in b488c580aef4e05f, but it seems quite useless to have split it out as a separate header, since only commands/opclasscmds.c uses it. My attention got drawn to it because the current patch proposes to #include it in

Re: [HACKERS] WIP: Rework access method interface

Tom Lane wrote: > ... btw, what is the point of catalog/opfam_internal.h? I see you added > it in b488c580aef4e05f, but it seems quite useless to have split it out > as a separate header, since only commands/opclasscmds.c uses it. > > My attention got drawn to it because the current patch

Re: [HACKERS] WIP: Rework access method interface

Tom Lane wrote: > Alvaro Herrera writes: > > Tom Lane wrote: > >> ... btw, what is the point of catalog/opfam_internal.h? I see you added > >> it in b488c580aef4e05f, but it seems quite useless to have split it out > >> as a separate header, since only

Re: [HACKERS] WIP: Rework access method interface

Tom Lane wrote: > Alvaro Herrera writes: > > Tom Lane wrote: > >>> ... btw, what is the point of catalog/opfam_internal.h? > > > The whole point of splitting the struct declaration to a new header was > > to get a DDL deparser to examine the list of objects being

Re: [HACKERS] WIP: Rework access method interface

Alvaro Herrera writes: > Tom Lane wrote: >> I'm kind of inclined to just let the verifiers read the catalogs for >> themselves. AFAICS, a loop around the results of SearchSysCacheList >> is not going to be significantly more code than what this patch does, >> and it

Re: [HACKERS] WIP: Rework access method interface

Alvaro Herrera writes: > Tom Lane wrote: >>> ... btw, what is the point of catalog/opfam_internal.h? > The whole point of splitting the struct declaration to a new header was > to get a DDL deparser to examine the list of objects being created, so > that it could

Re: [HACKERS] WIP: Rework access method interface

On Thu, Oct 22, 2015 at 8:37 AM, Petr Jelinek wrote: > BTW I think this is ready for committer, except for the need to check docs > by native speaker. If so, could you update the entry of this patch accordingly? https://commitfest.postgresql.org/6/353/ -- Michael -- Sent via pgsql-hackers

Re: [HACKERS] WIP: Rework access method interface

On 2015-10-12 14:32, Alexander Korotkov wrote: Also, it was planned that documentation changes would be reviewed by native english speaker. BTW I think this is ready for committer, except for the need to check docs by native speaker. -- Petr Jelinek

Re: [HACKERS] WIP: Rework access method interface

Petr Jelinek writes: > On 2015-10-12 14:32, Alexander Korotkov wrote: >> Also, it was planned that documentation changes would be reviewed by >> native english speaker. > BTW I think this is ready for committer, except for the need to check > docs by native speaker. I'm

Re: [HACKERS] WIP: Rework access method interface

On 2015-10-05 19:25, Alexander Korotkov wrote: On Sun, Oct 4, 2015 at 4:27 PM, Amit Kapila > wrote: On Sat, Oct 3, 2015 at 5:07 PM, Petr Jelinek > wrote: On 2015-10-03

Re: [HACKERS] WIP: Rework access method interface

On Sat, Oct 3, 2015 at 5:07 PM, Petr Jelinek wrote: > On 2015-10-03 08:27, Amit Kapila wrote: > >> On Fri, Oct 2, 2015 at 8:14 PM, Alexander Korotkov >> > wrote: >> > >> > >> > I agree about staying with one

Re: [HACKERS] WIP: Rework access method interface

Hi, this topic has seen a lot of activity/review. As development is ongoing I'm moving the patch to the next CF. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] WIP: Rework access method interface

On 2015-10-03 08:27, Amit Kapila wrote: On Fri, Oct 2, 2015 at 8:14 PM, Alexander Korotkov > wrote: > > > I agree about staying with one SQL-visible function. Okay, this does not necessarily mean there should be only one

Re: [HACKERS] WIP: Rework access method interface

On Fri, Oct 2, 2015 at 8:14 PM, Alexander Korotkov < a.korot...@postgrespro.ru> wrote: > > > I agree about staying with one SQL-visible function. > > Other changes: > * Documentation reflects interface changes. > * IndexAmRoutine moved from CacheMemoryContext to indexcxt. > * Various minor

Re: [HACKERS] WIP: Rework access method interface

On Fri, Sep 25, 2015 at 7:41 PM, Teodor Sigaev wrote: > I'm OK about continuing work on amvalidate if we can build consuensus on >> its design. >> Could you give some feedback on amvalidate version of patch please? >> >>

Re: [HACKERS] WIP: Rework access method interface

On 2015-09-25 17:45, Alvaro Herrera wrote: I think the API of getOpFamilyInfo is a bit odd; is the caller expected to fill intype and keytype always, and then it only sets the procs/opers lists? I wonder if it would be more sensible to have that routine receive the pg_opclass tuple (or even

Re: [HACKERS] WIP: Rework access method interface

Teodor Sigaev wrote: > >I'm OK about continuing work on amvalidate if we can build consuensus on its > >design. > >Could you give some feedback on amvalidate version of patch please? > >http://www.postgresql.org/message-id/capphfds8zywenz9vw6te5rzxbol1vu_wsw181veq+mu+v1d...@mail.gmail.com > > In

Re: [HACKERS] WIP: Rework access method interface

On Fri, Sep 25, 2015 at 6:25 PM, Tom Lane wrote: > Petr Jelinek writes: > > On 2015-09-25 16:11, Teodor Sigaev wrote: > >> In attach a bit modified patch based on 4-th version, and if there are > >> no strong objections, I will commit it. Waiting this

Re: [HACKERS] WIP: Rework access method interface

On 2015-09-25 16:11, Teodor Sigaev wrote: I'm OK about continuing work on amvalidate if we can build consuensus on its design. Could you give some feedback on amvalidate version of patch please?

Re: [HACKERS] WIP: Rework access method interface

Petr Jelinek writes: > On 2015-09-25 16:11, Teodor Sigaev wrote: >> In attach a bit modified patch based on 4-th version, and if there are >> no strong objections, I will commit it. Waiting this patch stops >> Alexander's development on CREATE ACCESS METHOD and he needs to

Re: [HACKERS] WIP: Rework access method interface

On 2015-09-18 14:58, Alexander Korotkov wrote: On Wed, Sep 16, 2015 at 8:44 PM, Teodor Sigaev > wrote: validate_opclass was renamed to amvalidate. It seems to me, that amvalidate method of AM should get as argument only Oid of

Re: [HACKERS] WIP: Rework access method interface

On Sun, Sep 20, 2015 at 5:02 PM, Petr Jelinek wrote: > On 2015-09-18 14:58, Alexander Korotkov wrote: > >> On Wed, Sep 16, 2015 at 8:44 PM, Teodor Sigaev > > wrote: >> >> validate_opclass was renamed to amvalidate. >> >>

Re: [HACKERS] WIP: Rework access method interface

Petr Jelinek writes: > On 2015-09-18 14:58, Alexander Korotkov wrote: >> After, further personal discussion with Teodor, we decided that >> amvalidate is out of scope for this patch. >> It's not evident what should we validate in amvalidate and which way. I >> think if we

Re: [HACKERS] WIP: Rework access method interface

On 2015-09-20 16:17, Alexander Korotkov wrote: On Sun, Sep 20, 2015 at 5:02 PM, Petr Jelinek

Re: [HACKERS] WIP: Rework access method interface

On Sun, Sep 20, 2015 at 5:18 PM, Tom Lane wrote: > Petr Jelinek writes: > > On 2015-09-18 14:58, Alexander Korotkov wrote: > >> After, further personal discussion with Teodor, we decided that > >> amvalidate is out of scope for this patch. > >> It's not

Re: [HACKERS] WIP: Rework access method interface

validate_opclass was renamed to amvalidate. It seems to me, that amvalidate method of AM should get as argument only Oid of operator family. Layout and meaning of amproc/amop fields are differ for different AM and there isn't an AM which implements all possible features. Actually, I'm a bit

Re: [HACKERS] WIP: Rework access method interface

On 2015-09-14 14:34, Oleg Bartunov wrote: Whhat I don't understand from this thread if we should wait 2ndQuadrant for their sequence and column AMs or just start to work on committing it ? Alvaro, where are you ? I don't see problems with this patch from the sequence am perspective. The

Re: [HACKERS] WIP: Rework access method interface

On Fri, Sep 11, 2015 at 4:22 PM, Alexander Korotkov < a.korot...@postgrespro.ru> wrote: > On Mon, Sep 7, 2015 at 9:17 PM, Petr Jelinek wrote: > >> On 2015-09-04 16:26, Alexander Korotkov wrote: >> >>> >>> Attached patch is implementing this. It doesn't pretend to be fully

Re: [HACKERS] WIP: Rework access method interface

On 2015-09-04 16:26, Alexander Korotkov wrote: Attached patch is implementing this. It doesn't pretend to be fully correct implementation, but it should be enough for proof the concept. In this patch access method exposes another function: amvalidate. It takes data structure representing

Re: [HACKERS] WIP: Rework access method interface

On Mon, Sep 7, 2015 at 10:02 PM, Petr Jelinek wrote: > On 2015-09-07 20:56, Alexander Korotkov wrote: > >> On Mon, Sep 7, 2015 at 9:17 PM, Petr Jelinek > >> However I don't like the naming differences between validate_opclass >> and

Re: [HACKERS] WIP: Rework access method interface

On Mon, Sep 7, 2015 at 9:17 PM, Petr Jelinek wrote: > On 2015-09-04 16:26, Alexander Korotkov wrote: > >> >> Attached patch is implementing this. It doesn't pretend to be fully >> correct implementation, but it should be enough for proof the concept. >> In this patch access

Re: [HACKERS] WIP: Rework access method interface

On 2015-09-07 20:56, Alexander Korotkov wrote: On Mon, Sep 7, 2015 at 9:17 PM, Petr Jelinek

Re: [HACKERS] WIP: Rework access method interface

On 2015-08-27 15:15, Alexander Korotkov wrote: On Wed, Aug 26, 2015 at 7:20 PM, Alexander Korotkov > wrote: On Wed, Aug 26, 2015 at 6:50 PM, Tom Lane > wrote: One thought

Re: [HACKERS] WIP: Rework access method interface

On Wed, Aug 26, 2015 at 7:20 PM, Alexander Korotkov a.korot...@postgrespro.ru wrote: On Wed, Aug 26, 2015 at 6:50 PM, Tom Lane t...@sss.pgh.pa.us wrote: Alexander Korotkov a.korot...@postgrespro.ru writes: OK. So, as we mentioned before, if we need to expose something of am parameters at

Re: [HACKERS] WIP: Rework access method interface

On Wed, Aug 26, 2015 at 6:50 PM, Tom Lane t...@sss.pgh.pa.us wrote: Alexander Korotkov a.korot...@postgrespro.ru writes: OK. So, as we mentioned before, if we need to expose something of am parameters at SQL-level then we need to write special functions which would call amhandler and

Re: [HACKERS] WIP: Rework access method interface

Alexander Korotkov a.korot...@postgrespro.ru writes: OK. So, as we mentioned before, if we need to expose something of am parameters at SQL-level then we need to write special functions which would call amhandler and expose it. Did we come to the agreement on this solution? I think we were

Re: [HACKERS] WIP: Rework access method interface

On Tue, Aug 25, 2015 at 7:20 PM, Tom Lane t...@sss.pgh.pa.us wrote: Jim Nasby jim.na...@bluetreble.com writes: On 8/25/15 10:56 AM, Tom Lane wrote: I'm good with this as long as all the things that get stored in pg_am are things that pg_class.relam can legitimately reference. If somebody

Re: [HACKERS] WIP: Rework access method interface

Alvaro Herrera alvhe...@2ndquadrant.com writes: Jim Nasby wrote: On 8/24/15 9:49 AM, Alexander Korotkov wrote: 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. In my reading of the thread,

Re: [HACKERS] WIP: Rework access method interface

On 8/24/15 9:49 AM, Alexander Korotkov wrote: 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

Re: [HACKERS] WIP: Rework access method interface

Jim Nasby wrote: On 8/24/15 9:49 AM, Alexander Korotkov wrote: 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

Re: [HACKERS] WIP: Rework access method interface

Jim Nasby wrote: On 8/25/15 10:56 AM, Tom Lane wrote: I'm good with this as long as all the things that get stored in pg_am are things that pg_class.relam can legitimately reference. If somebody proposed adding an access method kind that was not a relation access method, I'd probably push

Re: [HACKERS] WIP: Rework access method interface

On 8/25/15 10:56 AM, Tom Lane wrote: I'm good with this as long as all the things that get stored in pg_am are things that pg_class.relam can legitimately reference. If somebody proposed adding an access method kind that was not a relation access method, I'd probably push back on whether that

Re: [HACKERS] WIP: Rework access method interface

Jim Nasby jim.na...@bluetreble.com writes: On 8/25/15 10:56 AM, Tom Lane wrote: I'm good with this as long as all the things that get stored in pg_am are things that pg_class.relam can legitimately reference. If somebody proposed adding an access method kind that was not a relation access

Re: [HACKERS] WIP: Rework access method interface

Alexander Korotkov a.korot...@postgrespro.ru writes: On Mon, Aug 10, 2015 at 7:50 PM, Tom Lane t...@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.

Re: [HACKERS] WIP: Rework access method interface

On Mon, Aug 24, 2015 at 5:15 PM, Tom Lane t...@sss.pgh.pa.us wrote: Alexander Korotkov a.korot...@postgrespro.ru writes: On Mon, Aug 10, 2015 at 7:50 PM, Tom Lane t...@sss.pgh.pa.us wrote: Hm. So one way or the other we're going to end up violating relational theory somewhere. OK, I

Re: [HACKERS] WIP: Rework access method interface

Alexander Korotkov a.korot...@postgrespro.ru writes: On Mon, Aug 10, 2015 at 1:12 PM, Petr Jelinek p...@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

Re: [HACKERS] WIP: Rework access method interface

On Mon, Aug 10, 2015 at 6:36 PM, Petr Jelinek p...@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

Re: [HACKERS] WIP: Rework access method interface

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

Re: [HACKERS] WIP: Rework access method interface

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

Re: [HACKERS] WIP: Rework access method interface

On Mon, Aug 10, 2015 at 5:48 PM, Tom Lane t...@sss.pgh.pa.us wrote: Alexander Korotkov a.korot...@postgrespro.ru writes: On Mon, Aug 10, 2015 at 1:12 PM, Petr Jelinek p...@2ndquadrant.com wrote: I don't understand this, there is already AmRoutine in RelationData, why the need for

Re: [HACKERS] WIP: Rework access method interface

On 2015-08-10 17:47, Tom Lane wrote: Petr Jelinek p...@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

Re: [HACKERS] WIP: Rework access method interface

On 2015-08-10 18:08, Tom Lane wrote: Alexander Korotkov a.korot...@postgrespro.ru writes: On Mon, Aug 10, 2015 at 6:47 PM, Tom Lane t...@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

Re: [HACKERS] WIP: Rework access method interface

On Mon, Aug 10, 2015 at 6:47 PM, Tom Lane t...@sss.pgh.pa.us wrote: Petr Jelinek p...@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

Re: [HACKERS] WIP: Rework access method interface

Alvaro Herrera alvhe...@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

Re: [HACKERS] WIP: Rework access method interface

On 2015-08-10 16:58, Alexander Korotkov wrote: On Mon, Aug 10, 2015 at 5:48 PM, Tom Lane t...@sss.pgh.pa.us mailto:t...@sss.pgh.pa.us wrote: Alexander Korotkov a.korot...@postgrespro.ru mailto:a.korot...@postgrespro.ru writes: On Mon, Aug 10, 2015 at 1:12 PM, Petr Jelinek

Re: [HACKERS] WIP: Rework access method interface

Petr Jelinek p...@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

Re: [HACKERS] WIP: Rework access method interface

Petr Jelinek p...@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

Re: [HACKERS] WIP: Rework access method interface

Alexander Korotkov a.korot...@postgrespro.ru writes: On Mon, Aug 10, 2015 at 6:47 PM, Tom Lane t...@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

Re: [HACKERS] WIP: Rework access method interface

Tom Lane wrote: Petr Jelinek p...@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

Re: [HACKERS] WIP: Rework access method interface

On 2015-08-09 23:56, Alexander Korotkov wrote: Hacker, some time before I proposed patches implementing CREATE ACCESS METHOD. http://www.postgresql.org/message-id/capphfdsxwzmojm6dx+tjnpyk27kt4o7ri6x_4oswcbyu1rm...@mail.gmail.com As I get from comments to my patches and also from Tom's comment

Re: [HACKERS] WIP: Rework access method interface

On Mon, Aug 10, 2015 at 1:12 PM, Petr Jelinek p...@2ndquadrant.com wrote: On 2015-08-09 23:56, Alexander Korotkov wrote: Hacker, some time before I proposed patches implementing CREATE ACCESS METHOD.