Ăș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? > 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/ >