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 > in a different direct

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 might not survive long) and on

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 plpgsql_call_ > handler in pl

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 they're fixable. > One item that I think could us

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 grade indeed as an exte

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 reasonable response to >> points #1 and #2 but isn't

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 they're fixable. > One item that I think could use som

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 the new amvalidate functions.

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 registered as committer for this

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 ne

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 amroutin

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 functions but it's something

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 mailto:p...@2ndquadrant.com>> wrote: On 2015-12-09 15:09, Alexander Korotkov wrote: ​Patch was rebased against current master. Any notes about current version of patch? It w

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 pa

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 not going to be significantly more code than wh

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 verifier will care about. In an

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 avoids presuming that we know

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 created, so > > that it could con

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 construct the deparsed command.

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 commands/opclasscmds.c uses it. > > > Oh, t

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 slipped in there, didn't i

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 propose

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 amapi.

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;", >> likewise for RelOptInfo, Foreign

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 an

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 down from using "Cost" and "

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

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 out at me right away is that

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 mail

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 working at Salesforce th

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 http://www.2ndQuadrant.c

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 mailto:amit.kapil...@gmail.com>> wrote: On Sat, Oct 3, 2015 at 5:07 PM, Petr Jelinek mailto:p...@2ndquadrant.com>> wrote: On 2015-10-03 08:27, Amit Kapila wrote: On Fri, Oct 2, 20

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 >> mailto:a.korot...@postgrespro.ru>> wrote: >> > >> > >> > I agree about staying with one SQL-visible function. >> > > Okay, this does not nece

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: http://www.postgresql.org/mailpref/pgsql-hacker

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 mailto:a.korot...@postgrespro.ru>> wrote: > > > I agree about staying with one SQL-visible function. Okay, this does not necessarily mean there should be only one validation function in the C struct t

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 forma

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? >> >> http://www.postgresql.org/message-id/capphfds8zywenz9vw6te5rzxbol1vu_wsw181v

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 the

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 patch stops > >> Alexander's development on

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 move >> forward. > The

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? http://www.postgresql.org/message-id/capphfds8zywenz9vw6te5rzxbol1vu_wsw181veq+mu+v1d...@mail.gmail.co

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 evident what should we validate in amvalid

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 I think it's ok to not do automatic validation during CREATE/ALTER just yet. And I also think it's much worse to implement a SQL API which exposes internals just for regression tests than having a C A

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 need amvalidate it should

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. >> >> >> It seems to me, that amvalidate meth

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 mailto:teo...@sigaev.ru>> wrote: 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

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 nex

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 >>> correct implementati

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 amvalidate. If you expect that the current amvalidate wi

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 Well either the amvalidate or the validate_opclass should be renamed IMHO, depending on which way the checking goes (one interface for everything with generic name or multiple interfaces for multiple

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 method exposes another

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 opclass

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 mailto:a.korot...@postgrespro.ru>> wrote: On Wed, Aug 26, 2015 at 6:50 PM, Tom Lane mailto:t...@sss.pgh.pa.us>> wrote: One thought here is that we might not want to just blindly duplic

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 wrote: > >> Alexander Korotkov writes: >> > OK. So, as we mentioned before, if we need to expose something of am >> > parameters at SQL-level then we need to write

Re: [HACKERS] WIP: Rework access method interface

On Wed, Aug 26, 2015 at 6:50 PM, Tom Lane wrote: > Alexander Korotkov 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 agreem

Re: [HACKERS] WIP: Rework access method interface

Alexander Korotkov 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 agreed that we should wr

Re: [HACKERS] WIP: Rework access method interface

On Tue, Aug 25, 2015 at 7:20 PM, Tom Lane wrote: > Jim Nasby 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 me

Re: [HACKERS] WIP: Rework access method interface

Jim Nasby 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 >> method, I'd prob

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 probab

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

Alvaro Herrera 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, we have a co

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

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 b

Re: [HACKERS] WIP: Rework access method interface

On Mon, Aug 24, 2015 at 5:15 PM, Tom Lane wrote: > Alexander Korotkov writes: > > On Mon, Aug 10, 2015 at 7:50 PM, Tom Lane 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, > >> amha

Re: [HACKERS] WIP: Rework access method interface

Alexander Korotkov writes: > On Mon, Aug 10, 2015 at 7:50 PM, Tom Lane 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

Re: [HACKERS] WIP: Rework access method interface

Alvaro Herrera 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 th

Re: [HACKERS] WIP: Rework access method interface

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

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 d

Re: [HACKERS] WIP: Rework access method interface

On 2015-08-10 18:08, Tom Lane wrote: Alexander Korotkov writes: On Mon, Aug 10, 2015 at 6:47 PM, 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

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 functi

Re: [HACKERS] WIP: Rework access method interface

Petr Jelinek 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 gett

Re: [HACKERS] WIP: Rework access method interface

Alexander Korotkov writes: > On Mon, Aug 10, 2015 at 6:47 PM, 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

Re: [HACKERS] WIP: Rework access method interface

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

Re: [HACKERS] WIP: Rework access method interface

On Mon, Aug 10, 2015 at 6:47 PM, Tom Lane wrote: > Petr Jelinek 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 function

Re: [HACKERS] WIP: Rework access method interface

Petr Jelinek 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

Re: [HACKERS] WIP: Rework access method interface

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

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 mailto:t...@sss.pgh.pa.us>> wrote: Alexander Korotkov mailto:a.korot...@postgrespro.ru>> writes: > On Mon, Aug 10, 2015 at 1:12 PM, Petr Jelinek mailto:p...@2ndquadrant.com>> wrote: >> I don't un

Re: [HACKERS] WIP: Rework access method interface

On Mon, Aug 10, 2015 at 5:48 PM, Tom Lane wrote: > Alexander Korotkov writes: > > On Mon, Aug 10, 2015 at 1:12 PM, Petr Jelinek > wrote: > >> I don't understand this, there is already AmRoutine in RelationData, why > >> the need for additional field for just amsupport? > > > We need amsupport i

Re: [HACKERS] WIP: Rework access method interface

Alexander Korotkov writes: > On Mon, Aug 10, 2015 at 1:12 PM, Petr Jelinek 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'

Re: [HACKERS] WIP: Rework access method interface

On Mon, Aug 10, 2015 at 1:12 PM, Petr Jelinek wrote: > 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

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 a