Re: proposal: type info support functions for functions that use "any" type

út 14. 1. 2020 v 22:09 odesílatel Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> napsal:

> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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/
>