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 | CAFj8pRDbO5O-JK7tZYVJgKb0Jn67_T1sjmHPkdbtsn8EgQ1HqA@mail.gmail.com Whole thread Raw |
| In response to | Re: proposal: type info support functions for functions that use"any" type (Pavel Stehule <pavel.stehule@gmail.com>) |
| List | pgsql-hackers |
st 15. 1. 2020 v 11:04 odesílatel Pavel Stehule <pavel.stehule@gmail.com> napsal:
ú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?
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/
pgsql-hackers by date: