Re: [HACKERS] pow support for pgbench
От | Fabien COELHO |
---|---|
Тема | Re: [HACKERS] pow support for pgbench |
Дата | |
Msg-id | alpine.DEB.2.20.1712031007040.11574@lancre обсуждение исходный текст |
Ответ на | Re: [HACKERS] pow support for pgbench (Fabien COELHO <coelho@cri.ensmp.fr>) |
Список | pgsql-hackers |
>> The fact that the return type is not consistently of one type bothers >> me. I'm not sure pgbench's expression language is a good place to >> runtime polymorphism -- SQL doesn't work that way. > > Sure. > > Pg has a NUMERIC adaptative precision version, which is cheating, because it > can return kind of an "int" or a "float", depending on whether there are > digits after the decimal point or not. > > Pgbench does not have support for NUMERIC, just INT & DOUBLE, so the current > version is an approximation of that. > > Now it is always possible to just do DOUBLE version, but this won't match SQL > behavior either. Another point I forgot: pgbench functions and operators are notably interesting to generate/transform keys in tables, which are usually integers, so having int functions when possible/appropriate is desirable, which explain why I pushed for having an int version for POW. Also, pgbench does not have a static typing model because variable types are not declared "\set i ...", so the type is somehow "guessed" based on the string values, although if in doubt it is always possible to convert (with "int" & "double" functions). So for me the philosophy is to have expression match SQL behavior when possible, as closely as possible, but it is not an exact match. -- Fabien.
В списке pgsql-hackers по дате отправления: