Thread: Re: [PATCHES] guc
Liam Stewart writes:
> I've removed
> GetConfigOption() and replaced it with ShowConfigOption() which does an
> elog(NOTICE) instead of returning a string.
I certainly don't like that. I want to be able to get at the
configuration setting without any notice going off.
> When setting REAL_FORMAT and DOUBLE_PRECISION_FORMAT, the printf-style
> format string should be checked for certain things:
I wouldn't use a printf format string at all. It's not user-friendly --
not everyone is a C programmer, in fact most people aren't. It leaves
open too many ways to shoot yourself in the foot. And if you plan to
close all those ways you end up with a crippled system that is still
complex to understand for many.
What I would like to get out of the configurability of floating-point
numbers is:
1. The ability to dump them in binary or hex format for lossless dump/reload. (printf("%a") does that.) That could
bea boolean setting.
2. To have (at least as an option) the same output format on all platforms. Not sure how to approach that, perhaps it
hasnothing to do with configurability.
Some people will also suggest
3. Be able to set the number of significant digits that are shown.
to allow simplifying the regression tests, but I do not think that that is
a good idea, because
a. If platforms behave differently, the test suite should not paint over that; it might be important information.
b. If we actually break floating-point operations one day, we might miss it.
c. Types represent data, data is altered by functions (round? truncate?). Global side-effects are evil.
d. Input and output would not be inverses anymore.
--
Peter Eisentraut peter_e@gmx.net
Peter Eisentraut <peter_e@gmx.net> writes:
> Liam Stewart writes:
>> I've removed
>> GetConfigOption() and replaced it with ShowConfigOption() which does an
>> elog(NOTICE) instead of returning a string.
> I certainly don't like that. I want to be able to get at the
> configuration setting without any notice going off.
I agree with Peter --- better to separate the getting of the string
from displaying it. What's the reason for collapsing them together?
>> When setting REAL_FORMAT and DOUBLE_PRECISION_FORMAT, the printf-style
>> format string should be checked for certain things:
> I wouldn't use a printf format string at all.
Good point. If we have to set up a checking mechanism then we should
ask ourselves why we're bothering to use printf representation.
> What I would like to get out of the configurability of floating-point
> numbers is:
> 1. The ability to dump them in binary or hex format for lossless
> dump/reload. (printf("%a") does that.)
On some platforms... I'd be happier with this if it were more portable...
> Some people will also suggest
> 3. Be able to set the number of significant digits that are shown.
> to allow simplifying the regression tests, but I do not think that that is
> a good idea,
[ raises eyebrow ] To my mind that was one of the principal reasons
for working on such a thing at all. If you don't want to allow this,
then what alternative solution do you have for our geometry regression
test mess? (Defining it as not a mess won't fly.)
regards, tom lane
> > Some people will also suggest > > 3. Be able to set the number of significant digits that are shown. > > > to allow simplifying the regression tests, but I do not think that that is > > a good idea, > > [ raises eyebrow ] To my mind that was one of the principal reasons > for working on such a thing at all. If you don't want to allow this, > then what alternative solution do you have for our geometry regression > test mess? (Defining it as not a mess won't fly.) Yes, I doubt the current regression are tests are input/output reversable because of the rounding anyway. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Tom Lane writes: > [ raises eyebrow ] To my mind that was one of the principal reasons > for working on such a thing at all. If you don't want to allow this, > then what alternative solution do you have for our geometry regression > test mess? (Defining it as not a mess won't fly.) I did some investigation and noticed that the different geometry expected files differ in the same 5 groups of places (or less), and in 4 of those places there are only two possible variations. So that at least gives me the idea that perhaps the geometry test could be split up in two or three tests, and that would probably reduce the relative number of "nonstandard" expected files we'd need. One difference case is a system failing to implement negative zeros. Setting the output precision won't fix that. Actually, I just took a peak into include/utils/geo_decls.h, and the definiton of EPSILON at the top leaves me to think that printing out anything more than 6 significant digits is nonsense anyway. Numerical analysts would probably shudder. -- Peter Eisentraut peter_e@gmx.net
On Thu, Jan 17, 2002 at 05:57:29PM -0500, Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > Liam Stewart writes:
> >> I've removed
> >> GetConfigOption() and replaced it with ShowConfigOption() which does an
> >> elog(NOTICE) instead of returning a string.
>
> > I certainly don't like that. I want to be able to get at the
> > configuration setting without any notice going off.
>
> I agree with Peter --- better to separate the getting of the string
> from displaying it. What's the reason for collapsing them together?
I ended up thinking that GetConfigOption was a bit useless right now
since, with the redone GetPGVariable, there's currently nothing that
would use it. I can see some use for it since not all guc options have
an associated variable but still have a value (e.g.: seed,
server_encoding). How about I add GetConfigOption back in and change
ShowConfigOption to use it. display_proc hooks would return a char *;
GetConfigOption would use a variable's display_proc hook if it is
non-null instead of doing its own thing. ShowConfigOption would no
longer call a variable's display_proc hook.
> > I wouldn't use a printf format string at all.
>
> Good point. If we have to set up a checking mechanism then we should
> ask ourselves why we're bothering to use printf representation.
I was going on the fact that printf format string was on the todo and
that Tom suggested using them last February. When thinking about parsing
printf strings, I realized how not nice it would be, so I'm alright
with a new representation.
> > What I would like to get out of the configurability of floating-point
> > numbers is:
> > 1. The ability to dump them in binary or hex format for lossless
> > dump/reload. (printf("%a") does that.)
>
> On some platforms... I'd be happier with this if it were more portable...
Roll our own? %a and %A are C99 so are much less portable than most
other printf conversion specifiers.
Liam
--
Liam Stewart :: Red Hat Canada, Ltd. :: liams@redhat.com
Liam Stewart <liams@redhat.com> writes:
>>> What I would like to get out of the configurability of floating-point
>>> numbers is:
>>> 1. The ability to dump them in binary or hex format for lossless
>>> dump/reload. (printf("%a") does that.)
>>
>> On some platforms... I'd be happier with this if it were more portable...
> Roll our own? %a and %A are C99 so are much less portable than most
> other printf conversion specifiers.
Hmm ... rolling our own might actually not be too unreasonable ...
and the lack of lossless dump/reload for floats has certainly been
a sore point for a long time, so expending some effort here is
justified.
regards, tom lane