Re: proposal: type info support functions for functions that use"any" type
| От | Pavel Stehule |
|---|---|
| Тема | Re: proposal: type info support functions for functions that use"any" type |
| Дата | |
| Msg-id | CAFj8pRB3hm-qD1sZe_gVeHqmvP6Ws3F2caa4BzgkHwopeaq6ZQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: proposal: type info support functions for functions that use "any" type (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: proposal: type info support functions for functions that use "any" type
|
| Список | pgsql-hackers |
Hi
ú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.
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;
+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/
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Magnus HaganderДата:
Сообщение: Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?)
Следующее
От: Justin PryzbyДата:
Сообщение: Re: explain HashAggregate to report bucket and memory stats