Re: Ryu floating point output patch
От | Andrew Gierth |
---|---|
Тема | Re: Ryu floating point output patch |
Дата | |
Msg-id | 87pnrqjuxw.fsf@news-spur.riddles.org.uk обсуждение исходный текст |
Ответ на | Re: Ryu floating point output patch (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>) |
Ответы |
Re: Ryu floating point output patch
|
Список | pgsql-hackers |
>>>>> "Andrew" == Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes: >> [horrible environment variable hack] >> >> We might not want to use that in more real-world cases of pg_dump use, >> but I think for this purpose it should be fine. Andrew> I haven't seen a response to this. Cross version upgrade Andrew> testing is still broken. I don't think we need a GUC to fix it, Andrew> but we do need this or a new switch to tell pg_dump what to set Andrew> extra_float_digits to, unless someone has a better idea. I'd been holding off responding in the hope of other opinions, but for what it's worth, I *really* dislike having pg_dump depend magically on some new environment variable. I would suggest instead: a) pg_dump could check if PGOPTIONS or the connect string contained an extra_float_digits setting and defer to that if so. Downside of this is that if someone is already using that in the environment and pg_dump suddenly starts respecting it, they could get imprecise values in their dumps unexpectedly. Option (a2) would be to honour extra_float_digits only if it showed up in a connect string and not in PGOPTIONS, which would be more explicit. b) new command-line option, e.g. pg_dump --extra-float-digits=0 This is probably the safest option, IMO. Any preferences as to the option name? -- Andrew (irc:RhodiumToad)
В списке pgsql-hackers по дате отправления: