Re: Custom Scans and private data - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Custom Scans and private data
Date
Msg-id 24050.1440544924@sss.pgh.pa.us
Whole thread Raw
In response to Re: Custom Scans and private data  (Andres Freund <andres@anarazel.de>)
Responses Re: Custom Scans and private data  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2015-08-25 14:42:32 -0400, Tom Lane wrote:
>> In any case, since this convention already exists for FDWs I'm not
>> sure why we should make it different for CustomScan.

> I think it was a noticeable mistake in the fdw case, but we already
> released with that. We shouldn't make the same mistake twice.

I don't agree that it was a mistake, and I do think there is value in
consistency.

In the case at hand, it would not be too hard to provide some utility
functions for some common cases; for instance, if you want to just store
a struct, we could offer convenience functions to wrap that in a bytea
constant and unwrap it again.  Those could be useful for both FDWs and
custom scans.

(The bigger picture here is that we always intended to offer a bunch of
support functions to make writing FDWs easier, once we'd figured out
what made sense.  The fact that we haven't done that work yet doesn't
make it a bad approach.  Nor does "shove it all into some callbacks"
mean that the callbacks will be easy to write.)

> Looking at
> postgres_fdw and the pg-strom example linked upthread imo pretty clearly
> shows how ugly this is.  There's also the rather noticeable difference
> that we already have callbacks in the node for custom scans (used by
> outfuncs), making this rather trivial to add.

I will manfully refrain from taking that bait.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Commitfest remaining "Needs Review" items
Next
From: Tom Lane
Date:
Subject: Re: Function accepting array of complex type