Hi ú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. > > I reread all related mails and I think so it should be safe - or there is same risk like using any C extensions for functions or hooks. I use a example from demo +CREATE FUNCTION decode_support(internal) +RETURNS internal +AS 'MODULE_PATHNAME' +LANGUAGE C IMMUTABLE STRICT PARALLEL SAFE; + +-- +-- decode function - example of function that returns "any" type +-- +CREATE FUNCTION decode(variadic "any") +RETURNS "any" +AS 'MODULE_PATHNAME' +LANGUAGE C IMMUTABLE STRICT PARALLEL SAFE SUPPORT decode_support; The support function (and implementation) is joined with "decode" function. So I cannot to change the behave of support function without reloading a extension, and it needs typically session reconnect. > 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].) > The design is based not on values, just on types. I don't need to know a value, I need to know a type. Currently our polymorphism is not enough - and is necessary to use "any" datatype. This patch just add a possibility to use "any" as return type. I spent on this topic lot of time and one result is patch [1]. This patch increase situation lot of, but cannot to cover all. There are strong limits for variadic usage. This patch is really not about values, it is about types - and about more possibility (and more elasticity) to control result type. > 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? > It is working with "any" type, and then it can be very small, because the all work with this type is moved to extension. > On the whole I think we should reject this idea. > I will accept any your opinion. Please, try to understand to me as Orafce developer, maintainer. I would to clean this extension, and current state of polymorphism (with patch [1]) doesn't allow it. I am open to any proposals, ideas. Regards Pavel > regards, tom lane > > [1] https://commitfest.postgresql.org/26/1911/ >
