Re: Custom/Foreign-Join-APIs (Re: [v9.5] Custom Plan API)

On Sun, May 10, 2015 at 11:07 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> On 2015-05-10 22:51:33 -0400, Robert Haas wrote:
>> > And there's definitely some things
>> > around that pretty much only still exist because changing them would
>> > break too much stuff.
>>
>> Such as what?
>
> Without even thinking about it:
> * linitial vs lfirst vs lnext. That thing still induces an impedance
> mismatch when reading code for me, and I believe a good number of
> other people.
> * Two 'string buffer' APIs with essentially only minor differences.
> * A whole bunch of libpq APIs. Admittedly that's a bit more exposed than
> lots of backend only things.
> * The whole V0 calling convention that makes it so much easier to get
> odd crashes.
>
> Admittedly that's all I could come up without having to think. But I do
> vaguely remember a lot of things we did not do because of bwcompat
> concerns.

I see your point, but I don't think it really detracts from mine. The
fact that we have a few inconsistently-named list functions is not
preventing any core development project that would otherwise get
completed to instead not get completed. Nor is any of that other
stuff, except maybe the libpq API, but that's a lot (not just a bit)
more exposed.

Also, I'd actually be in favor of looking for a way to identify the
StringInfo and PQexpBuffer stuff - and of partially deprecating the V0
calling convention.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company