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

st 15. 1. 2020 v 11:04 odesílatel Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
napsal:

>
>
> ú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?
>

When we check, so used function is started from dynamic loaded extension,
we can raise a error. It's not too great for upgrades, but I expect upgrade
of this kind extension is very similar like Postgres - and the restart can
be together.

>
>> 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.
>

All this discussion is motivated by my work on Orafce extension -
https://github.com/orafce/orafce

Unfortunately implementation of "decode" functions is not possible with
patch [1]. Now I have 55 instances of "decode" function and I am sure, I
don't cover all.

With this patch (polymorphism on stereoids :)), I can do it very simple,
and quickly. This functions and other similar.

The patch was very simple, so I think, maybe wrongly, so it is acceptable
way.

Our polymorphism is strong, and if I design code natively for Postgres,
than it is perfect. But It doesn't allow to implement some simple functions
that are used in other databases. With this small patch I can cover almost
all situations - and very simply.

I don't want to increase complexity of polymorphism rules more - [1] is
maximum, what we can implement with acceptable costs, but this generic
system is sometimes not enough.

But I invite any design, how this problem can be solved.

Any ideas?

>
>
>> 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/
>>
>