Fabien COELHO writes:
>> Neither way allows for trailing whitespace, though. I don't see that
>> that's important here.
> No, this is not an issue here for variables specified from the command
> line. Consider pushing this fix?
Done already.
regards, tom lane
--
Sen
While testing the patch I found a minor preexisting (mine...) bug: when
string-scanning doubles, whether the whole string is consumed or not is
not checked. This means that -D x=0one is interpreted as double 0.
I came up with the attached check, but maybe there is a cleaner way to do
that.
Fabien COELHO writes:
> This is a definite improvement.
> I like the lazyness between string & numeric forms, and for sorting, that
> is what was needed doing to have something clean.
> Applied on head, it works for me.
OK, pushed.
> While testing the patch I found a minor preexisting (mine..
Hello Tom,
That's probably a bigger change than we want to be putting in right now,
though I'm a bit tempted to go try it.
I definitely agree that the text variable solution is pretty ugly, but it
was the minimum change solution, and I do not have much time available.
Well, I felt like doi
Fabien COELHO writes:
>> A better answer, perhaps, would be to store double-valued variables in
>> double format to begin with, coercing to text only when and if the value
>> is interpolated into a string.
> Yep, but that was yet more changes for a limited benefit and would have
> increase the
Hello Tom,
While testing 7a622b273 I happened to notice this:
\set x greatest(3, 2, 4.9)
create table mytab (x numeric);
insert into mytab values(:x);
x
--
4.900355
The reason for that is that the result of a "double" calculation
is coerced to text lik
While testing 7a622b273 I happened to notice this:
\set x greatest(3, 2, 4.9)
create table mytab (x numeric);
insert into mytab values(:x);
results in this table:
x
--
4.900355
(1 row)
The reason for that is that the result of a "double" cal