Re: proposal: type info support functions for functions that use"any" type - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: proposal: type info support functions for functions that use"any" type
Date
Msg-id CAFj8pRDc6h-e83-cO8i4zG_gXMVPZUoVwNLnRtx-Kwrqe3bPaA@mail.gmail.com
Whole thread Raw
In response to Re: proposal: type info support functions for functions that use "any" type  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: proposal: type info support functions for functions that use"any" type  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers


út 14. 1. 2020 v 22:09 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:
Pavel Stehule <pavel.stehule@gmail.com> writes:
>  [ parser-support-function-with-demo-20191128.patch ]

TBH, I'm still not convinced that this is a good idea.  Restricting
the support function to only change the function's return type is
safer than the original proposal, but it's still not terribly safe.
If you change the support function's algorithm in any way, how do
you know whether you've broken existing stored queries?  If the
support function consults external resources to make its choice
(perhaps checking the existence of a cast), where could we record
that the query depends on the existence of that cast?  There'd be
no visible trace of that in the query parsetree.

This risk is real and cannot be simply solved without more complications.

Can be solution to limit and enforce this functionality only for extensions that be initialized from shared_preload_libraries or local_preload_libraries?


I'm also still not convinced that this idea allows doing anything
that can't be done just as well with polymorphism.  It would be a
really bad idea for the support function to be examining the values
of the arguments (else what happens when they're not constants?).
So all you can do is look at their types, and then it seems like
the things you can usefully do are pretty much like polymorphism,
i.e. select some one of the input types, or a related type such
as an array type or element type.  If there are gaps in what you
can express with polymorphism, I'd much rather spend effort on
improving that facility than in adding something that is only
accessible to advanced C coders.  (Yes, I know I've been slacking
on reviewing [1].)

For my purpose critical information is type. I don't need to work with constant, but I can imagine, so some API can be nice to work with constant value.
Yes, I can solve lot of things by patch [1], but not all, and this patch shorter, and almost trivial.


Lastly, I still think that this patch doesn't begin to address
all the places that would have to know about the feature.  There's
a lot of places that know about polymorphism --- if this is
polymorphism on steroids, which it is, then why don't all of those
places need to be touched?

I am sorry, I don't understand  last sentence?


On the whole I think we should reject this idea.

                        regards, tom lane

[1] https://commitfest.postgresql.org/26/1911/

pgsql-hackers by date:

Previous
From: "Leif Gunnar Erlandsen"
Date:
Subject: Re: pause recovery if pitr target not reached
Next
From: Georgios Kokolatos
Date:
Subject: Re: Duplicate Workers entries in some EXPLAIN plans