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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Allowing extensions to supply operator-/function-specific info
Date: 2019-01-28 17:51:25
Message-ID: 19993.1548697885@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Sat, Jan 26, 2019 at 12:35 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Elvis Pranskevichus 2019-01-28 17:52:57 Re: [PATCH] Allow anonymous rowtypes in function return column definition
Previous Message Stephen Frost 2019-01-28 17:01:08 Re: pgsql: Remove references to Majordomo