Pavel Stehule <pavel.steh...@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.
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].)
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?
On the whole I think we should reject this idea.
regards, tom lane
[1] https://commitfest.postgresql.org/26/1911/
