st 15. 1. 2020 v 11:04 odesílatel Pavel Stehule <pavel.steh...@gmail.com> napsal:
> > > út 14. 1. 2020 v 22:09 odesílatel Tom Lane <t...@sss.pgh.pa.us> napsal: > >> 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. >> > > 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/ >> >
