From: Tom Lane <tgl@sss.pgh.pa.us>
To: Paul Ramsey <pramsey@cleverelephant.ca>
cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Allowing extensions to supply operator-/function-specific info
In-reply-to: <74C11775-67A7-48D2-B1E3-24C52A686F86@cleverelephant.ca>
References: <15193.1548028093@sss.pgh.pa.us> <6953.1548297558@sss.pgh.pa.us>
 <6044.1548524131@sss.pgh.pa.us>
 <CA+TgmoYkLjVcbZZ8PYyaCTMYZJCQ8eiod8MSRMDaczjBw=a0bQ@mail.gmail.com>
 <19993.1548697885@sss.pgh.pa.us>
 <CACowWR3jZ4Xo1atU5xTDpEoeeKSw1==sKPhCy3a29HtcE9oQVQ@mail.gmail.com>
 <7671.1551135674@sss.pgh.pa.us>
 <CACowWR3_RyPSYO6a8TVLZ7KnL_rDNh2ywkSTeqFmrAPpP4y6-g@mail.gmail.com>
 <11051.1551139751@sss.pgh.pa.us>
 <CACowWR1ycbLx0t7WwT8uuJnK7E3U+tfzKXBRPaQrgHiCG+hvbA@mail.gmail.com>
 <14747.1551219541@sss.pgh.pa.us>
 <91BAE1F4-7C16-4F87-849F-B01175A8D7D8@cleverelephant.ca>
 <17244.1551226168@sss.pgh.pa.us>
 <74C11775-67A7-48D2-B1E3-24C52A686F86@cleverelephant.ca>
Comments: In-reply-to Paul Ramsey <pramsey@cleverelephant.ca>
	message dated "Wed, 27 Feb 2019 15:11:02 -0800"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <15085.1551310830.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Wed, 27 Feb 2019 18:40:30 -0500
Message-ID: <15086.1551310830@sss.pgh.pa.us>
Precedence: bulk

Paul Ramsey <pramsey@cleverelephant.ca> writes:
> The documentation says that a support function should have a signature "=
supportfn(internal) returns internal=E2=80=9D, but doesn=E2=80=99t say whi=
ch (if any) annotations should be provided. IMMUTABLE? PARALLEL SAFE? STRI=
CT? None? All?

It doesn't matter much given that these things aren't callable from SQL.
The builtin ones are marked immutable/safe/strict, but that's mostly
because that's the default state for builtin functions.  The only one
I'd get excited about is marking it strict if you're not going to check
for a null argument ... and even that is neatnik-ism, not something that
will have any practical effect.

> Variable SupportRequestCost is very exciting, but given that variable co=
st is usually driven by the complexity of arguments, what kind of argument=
 is the SupportRequestCost call fed during the planning stage? Constant ar=
guments are pretty straight forward, but what gets sent in when a column i=
s one (or all) of the arguments? =


You'll see whatever is in the post-constant-folding parse tree.  If it's a
Const, you can look at the value.  If it's a Var, you could perhaps look
at the pg_statistic info for that column, though whether that would give
you much of a leg up for cost estimation is hard to say.  For any sort of
expression, you're probably going to be reduced to using a default
estimate.  The core code generally doesn't try to be intelligent about
anything beyond the Const and Var cases.

			regards, tom lane