Re: Re: Use int8 for int4/int2 aggregate accumulators?
От | Tom Lane |
---|---|
Тема | Re: Re: Use int8 for int4/int2 aggregate accumulators? |
Дата | |
Msg-id | 20403.997823116@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Use int8 for int4/int2 aggregate accumulators? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Re: Use int8 for int4/int2 aggregate accumulators?
|
Список | pgsql-hackers |
Peter Eisentraut <peter_e@gmx.net> writes: > What I had in mind was to allow type conversion between the same > TypeCategory(). The SQL function analyzer is extraordinarily picky: I just finished looking at that. It'd be possible (and probably reasonable) to accept a binary-compatible datatype rather than requiring exact equality; this would fix your varchar-vs-text example. However, inserting any runtime type conversion would require a significant amount of code added. We couldn't do it just by inserting the conversion function call into the SELECT querytree, because that'd alter the SELECT semantics, if not actively crash it --- an example of a likely crash is create function mymax() returns int4 as ' select int8col from tab order by int8col desc limit 1'language sql; Here, the prepared parsetree is already set up to apply int8 sorting to the first column of its result. If we try to insert a cast-to-int4, we will end up sorting int4 data with int8 operators -- instant coredump. So the conversion function application would have to be done at runtime in the SQL function manager, which is more code than I care to take on at the moment. Note also that there is code in there to figure out whether a targetlist satisfies a tuple return datatype; should we also apply automatic type conversion to elements of such a list? It's getting to be more of a stretch to say that this is being helpful rather than masking programmer error. But binary compatibility is easy. Shall we do that? regards, tom lane
В списке pgsql-hackers по дате отправления: