Horton

Re: Allowing extensions to supply operator-/function-specific info

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-01-28T17:51:25Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Allow extensions to generate lossy index conditions.

  2. Build out the planner support function infrastructure.

  3. Create the infrastructure for planner support functions.

  4. Disable transforms that replaced AT TIME ZONE with RelabelType.

Robert Haas <robertmhaas@gmail.com> writes:
> On Sat, Jan 26, 2019 at 12:35 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Attached is an 0004 that makes a stab at providing some intelligence
>> for unnest() and the integer cases of generate_series().

> That looks awesome.

> I'm somewhat dubious about whole API.  It's basically -- if you have a
> problem and a PhD in PostgreSQL-ology, you can write some C code to
> fix it.  On the other hand, the status quo is that you may as well
> just forget about fixing it, which is clearly even worse.  And I don't
> really know how to do better.

Well, you need to be able to write a C extension :-(.  I kinda wish
that were not a requirement, but in practice I think the main audience
is people like PostGIS, who already cleared that bar.  I hope that
we'll soon have a bunch of examples, like those in the 0004 patch,
that people can look at to see how to do things in this area.  I see
no reason to believe it'll be all that much harder than anything
else extension authors have to do.

			regards, tom lane