> "Tom" == Tom Lane writes:
Tom> typedef char bool;
Tom> #endif
Tom> I believe that we could suppress these warnings by changing that
Tom> last to be
Tom> typedef unsigned char bool;
After testing this locally with a hand-tweaked configure result (since I
don't have hardware that trig
On 2/17/19 6:49 PM, Tom Lane wrote:
> Andrew Gierth writes:
>> "Andrew" == Andrew Dunstan writes:
>> Andrew> Would you like to reformulate this, then?
>> How about:
>> Use the specified value of extra_float_digits when dumping
>> floating-point data, instead of the maximum available pr
Andrew Gierth writes:
> "Andrew" == Andrew Dunstan writes:
> Andrew> Would you like to reformulate this, then?
> How about:
> Use the specified value of extra_float_digits when dumping
> floating-point data, instead of the maximum available precision.
> Routine dumps made for backu
> "Andrew" == Andrew Dunstan writes:
Tom> I think we have to document it, but it can be fairly terse perhaps.
Tom> Use the specified value of extra_float_digits when dumping
Tom> floating-point data, rather than pg_dump's default.
Tom> I don't think we need to go into detail about when/
On 2/17/19 6:15 PM, Andrew Gierth wrote:
>> "Tom" == Tom Lane writes:
> > Andrew Dunstan writes:
> >> Here's a patch without docco. How much do we actually want to
> >> document this? I'm not sure it has any great value outside of
> >> cross-version upgrade testing.
>
> Tom> I think we
> "Tom" == Tom Lane writes:
> Andrew Dunstan writes:
>> Here's a patch without docco. How much do we actually want to
>> document this? I'm not sure it has any great value outside of
>> cross-version upgrade testing.
Tom> I think we have to document it, but it can be fairly terse perha
> "Tom" == Tom Lane writes:
>> Obviously I'll fix the warning, but how strict do you want to be
>> about the rest of the code?
Tom> Well, given that we're now requiring C99 compilers, you'd think
Tom> that assuming stdbool semantics would be all right. The problem on
Tom> prairiedog and
Andrew Dunstan writes:
> Here's a patch without docco. How much do we actually want to document
> this? I'm not sure it has any great value outside of cross-version
> upgrade testing.
I think we have to document it, but it can be fairly terse perhaps.
Use the specified value of extra_flo
On 2/17/19 12:09 PM, Andrew Gierth wrote:
>> "Andrew" == Andrew Dunstan writes:
> Andrew> There are all sorts of version-specific things done there. The
> Andrew> code will be pretty minimal. We'll only invoke it if the target
> Andrew> version is >= 12 and the source version is <= 11.
>
>
Andrew Gierth writes:
> Tom> IMO, this is just awful coding, using a "bool" argument in just
> Tom> one place as a boolean and in four other ones as an integer. Aside
> Tom> from being cowboy coding, this has very serious risks of
> Tom> misbehaving on platforms where "bool" isn't C99-like, so
> "Tom" == Tom Lane writes:
Tom> result[sign] = '0';
Tom> IMO, this is just awful coding, using a "bool" argument in just
Tom> one place as a boolean and in four other ones as an integer. Aside
Tom> from being cowboy coding, this has very serious risks of
Tom> misbehaving on platforms
BTW, another minor problem with this patch: various buildfarm members
are whining that
prairiedog| 2019-02-17 14:25:15 | ryu_common.h:111: warning: array
subscript has type 'char'
This evidently is from the next-to-last line in
static inline int
copy_special_str(char *const result, const b
> "Andrew" == Andrew Dunstan writes:
Andrew> There are all sorts of version-specific things done there. The
Andrew> code will be pretty minimal. We'll only invoke it if the target
Andrew> version is >= 12 and the source version is <= 11.
Andrew> I can do this if we're agreed.
Sure, go a
On 2/17/19 11:19 AM, Andrew Gierth wrote:
>> "Tom" == Tom Lane writes:
> >> 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?
>
> Tom> I like that too, assuming that it can be made t
On 2/17/19 10:56 AM, Tom Lane wrote:
> Andrew Gierth writes:
>> 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.
> Likewise.
Sure, no problem here - that was just
> "Tom" == Tom Lane writes:
>> 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?
Tom> I like that too, assuming that it can be made to fit into the
Tom> structure of the cross-version-up
Andrew Gierth writes:
> 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.
Likewise.
> b) new command-line option, e.g. pg_dump --extra-float-digits=0
> This is probably
> "Andrew" == Andrew Dunstan 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
On 2/14/19 10:14 AM, Andrew Dunstan wrote:
> On 2/13/19 12:09 PM, Andrew Gierth wrote:
>>> "Andrew" == Andrew Gierth writes:
>> Andrew> 2. How far do we need to go to support existing uses of
>> Andrew>extra_float_digits? For example, do we need a way for clients to
>> Andrew>requ
> "Andrew" == Andrew Dunstan writes:
Andrew> Rather than give you the files, I will just tell you, in both
Andrew> cases it is matching float8.out, not the small-is-zero file.
OK, thanks. That lets me fix the float4 failures in a reasonably
straightforward way.
--
Andrew (irc:RhodiumToad
On 2/14/19 12:42 PM, Andrew Dunstan wrote:
> On 2/14/19 12:24 PM, Andrew Gierth wrote:
>> Andrew,
>>
>> Is there any chance you can get me the regress/results/float[48].out
>> files from lorikeet and jacana? It would help a lot.
>>
>> Seeing the diffs isn't enough, because I want to know if the f
On 2/14/19 12:24 PM, Andrew Gierth wrote:
> Andrew,
>
> Is there any chance you can get me the regress/results/float[48].out
> files from lorikeet and jacana? It would help a lot.
>
> Seeing the diffs isn't enough, because I want to know if the float8 test
> (which passes, so there's no diff) is
Andrew,
Is there any chance you can get me the regress/results/float[48].out
files from lorikeet and jacana? It would help a lot.
Seeing the diffs isn't enough, because I want to know if the float8 test
(which passes, so there's no diff) is matching the standard file or the
-small-is-zero file.
On 2/13/19 12:09 PM, Andrew Gierth wrote:
>> "Andrew" == Andrew Gierth writes:
> Andrew> 2. How far do we need to go to support existing uses of
> Andrew>extra_float_digits? For example, do we need a way for clients to
> Andrew>request that they get the exact same output as previo
> "Andrew" == Andrew Gierth writes:
Andrew> 2. How far do we need to go to support existing uses of
Andrew>extra_float_digits? For example, do we need a way for clients to
Andrew>request that they get the exact same output as previously for
Andrew>extra_float_digits=2 or 3, ra
Andrew Gierth writes:
> [ ryu11.patch ]
I can confirm this compiles and passes core regression tests on
my HPPA dinosaur.
regards, tom lane
Andrew Gierth writes:
> [ ryu9.patch ]
I recall having tried some earlier version on my old HPUX dinosaur,
and it worked, but this one doesn't compile:
float.c: In function `float4in':
float.c:240: error: `HUGE_VALF' undeclared (first use in this function)
float.c:240: error: (Each undeclared id
> "Donald" == Donald Dong writes:
Donald> I wonder if it's necessary to update the doc accordingly?
Yes, I specifically mentioned that doc updates were needed, and that
they were not included because they depend on final decisions on the
various questions that I have asked.
--
Andrew (irc
> On Jan 19, 2019, at 5:12 PM, Andrew Gierth
> wrote:
>
>> "Donald" == Donald Dong writes:
>
> Donald> I think the previous additional digits behavior still exist
> Donald> in the latest patch. For example:
>
> Donald> =# set extra_float_digits = 0;
> Donald> SET
> Donald> =# select flo
> "Donald" == Donald Dong writes:
Donald> I think the previous additional digits behavior still exist
Donald> in the latest patch. For example:
Donald> =# set extra_float_digits = 0;
Donald> SET
Donald> =# select float4in('1.123456789');
Donald> float4in
Donald> --
Donald>
> On Jan 18, 2019, at 2:05 AM, Andrew Gierth
> wrote:
>
> BTW, doing that in a thread about a commitfest patch confuses the
> commitfest app and cfbot (both of which think it's a new version of the
> patch under discussion), so best avoided.
Oops. Thank you. Noted.
I think the previous addit
> "Andrew" == Andrew Gierth writes:
Andrew> 4. Passes regression tests
Well, almost. I missed a contrib module, and there's some issues with
rounding and subnormal values on Windows that I need to track down.
--
Andrew (irc:RhodiumToad)
> "Donald" == Donald Dong writes:
Donald> I attached my changes as a patch.
BTW, doing that in a thread about a commitfest patch confuses the
commitfest app and cfbot (both of which think it's a new version of the
patch under discussion), so best avoided.
--
Andrew (irc:RhodiumToad)
> "Donald" == Donald Dong writes:
Donald> Hi,
Donald> I'm trying to reproduce the results by calling float4in in my
Donald> test code. But I have some difficulties linking the code:
Donald> testfloat4.c:(.text+0x34): undefined reference to `float4in'
Donald> testfloat4.c:(.text+0x3c):
> On Jan 15, 2019, at 2:37 AM, Andrew Gierth
> wrote:
>
> Andres> strtod()'s job ought to computationally be significantly easier
> Andres> than the other way round, no? And if there's buggy strtod()
> Andres> implementations out there, why would they be guaranteed to do
> Andres> the correct t
Andrew Gierth writes:
> On a slightly unrelated note, is the small-is-zero variant output file
> for the float tests still required?
Hm, good question. I had been about to respond that it must be,
but looking more closely at pg_regress.c I see that the default
expected-file will be tried if the
> "Tom" == Tom Lane writes:
On a slightly unrelated note, is the small-is-zero variant output file
for the float tests still required?
--
Andrew (irc:RhodiumToad)
Andrew Gierth writes:
> Funny thing: I've been devoting considerable effort to testing this, and
> the one failure mode I've found is very interesting; it's not a problem
> with strtod(), in fact it's a bug in our float4in caused by _misuse_ of
> strtod().
> In particular, float4in thinks it's ok
> "Andres" == Andres Freund writes:
>> In particular, how does it know how every strtod() on the planet
>> will react to specific input?
Andres> strtod()'s job ought to computationally be significantly easier
Andres> than the other way round, no? And if there's buggy strtod()
Andres> im
On Sunday, January 13, 2019, Donald Dong wrote:
>
> Also I wonder why do we need to make this change?
> -intextra_float_digits = 0; /* Added to DBL_DIG or
> FLT_DIG */
> +intextra_float_digits = 1; /* Added to DBL_DIG or
> FLT_DIG */
>
>From the original po
> On Jan 11, 2019, at 10:40 AM, Andres Freund wrote:
>
> And of course it'd change the dump's text contents between ryu and
> non-ryu backends even with extra_float_digits = 3, but the resulting
> floats ought to be the same. It's just that ryu is better at figuring
> out what the minimal text
> "Andres" == Andres Freund writes:
>> 3. Do we need to do anything about how conversions from floats to
>> numeric work? At present they _ignore_ extra_float_digits
>> (presumably on immutability grounds) and convert using only DBL_DIG
>> digits of precision.
>>
>> I have no very stro
> "Andres" == Andres Freund writes:
>> 4. Can we allow declaration-after-statement please? That would allow
>> keeping this code significantly closer to its upstream.
Andres> As I said on IRC: I'm personally on-board with changing this
Andres> styilistic requirement, but I also think tha
Hi,
On 2019-01-11 14:54:55 -0500, Tom Lane wrote:
> Andres Freund writes:
> > And of course it'd change the dump's text contents between ryu and
> > non-ryu backends even with extra_float_digits = 3, but the resulting
> > floats ought to be the same. It's just that ryu is better at figuring
> > o
Andres Freund writes:
> And of course it'd change the dump's text contents between ryu and
> non-ryu backends even with extra_float_digits = 3, but the resulting
> floats ought to be the same. It's just that ryu is better at figuring
> out what the minimal text representation is than the current c
On Fri, Jan 11, 2019 at 1:40 PM Andres Freund wrote:
> It'd potentially change data between an non-ryu->{ryu,non-ryu} and
> ryu->ryu versions, for dumps that didn't specify extra_float_digits =
> 3. But that'd not be pg_dump, and already broken previously, so I don't
> have particularly much sympa
Hi,
On 2019-01-11 13:33:54 -0500, Robert Haas wrote:
> On Fri, Jan 11, 2019 at 1:30 PM Andres Freund wrote:
> > On 2019-01-11 12:55:54 -0500, Robert Haas wrote:
> > > About as much as I can say is that if you commit this patch, and as a
> > > result, a dump-and-restore from v11 to v12 causes a ch
On Fri, Jan 11, 2019 at 1:30 PM Andres Freund wrote:
> On 2019-01-11 12:55:54 -0500, Robert Haas wrote:
> > About as much as I can say is that if you commit this patch, and as a
> > result, a dump-and-restore from v11 to v12 causes a change in the bits
> > on disk that would not have occurred with
Hi,
On 2019-01-11 12:55:54 -0500, Robert Haas wrote:
> About as much as I can say is that if you commit this patch, and as a
> result, a dump-and-restore from v11 to v12 causes a change in the bits
> on disk that would not have occurred without this patch, that's very
> bad. What ramifications th
Hi,
On 2019-01-11 02:40:25 +, Andrew Gierth wrote:
> Decisions that need to be made in order to proceed:
>
> 1. Should exact output become the default, or is it more important to
>preserve the historical output?
>
> I will argue very strongly that the default output should be exact.
S
On Fri, Jan 11, 2019 at 12:33 PM Andrew Gierth
wrote:
> > "Robert" == Robert Haas writes:
> Robert> I don't have an opinion on the code that is part of this patch
>
> At this point, frankly, I'm less interested in opinions on the code
> itself (which can be addressed later if need be) than o
> "Robert" == Robert Haas writes:
Robert> I don't have an opinion on the code that is part of this patch
At this point, frankly, I'm less interested in opinions on the code
itself (which can be addressed later if need be) than on answers to (or
discussion of) the questions asked upthread.
On Thu, Jan 10, 2019 at 11:10 PM Tom Lane wrote:
> Andres Freund writes:
> > On 2019-01-10 23:02:01 -0500, Chapman Flack wrote:
> >> Does the project have an established view on non-ASCII names in
> >> sources or docs?
> >> AFAICS [1], the name of the algorithm may be Ryū.
>
> > I think it'd be a
Andres Freund writes:
> On 2019-01-10 23:02:01 -0500, Chapman Flack wrote:
>> Does the project have an established view on non-ASCII names in
>> sources or docs?
>> AFAICS [1], the name of the algorithm may be Ryū.
> I think it'd be a really bad idea to start having non-ascii
> filenames, and I q
Hi,
On 2019-01-10 23:02:01 -0500, Chapman Flack wrote:
> Does the project have an established view on non-ASCII names in
> sources or docs?
>
> AFAICS [1], the name of the algorithm may be Ryū.
I think it'd be a really bad idea to start having non-ascii
filenames, and I quite doubt that I'm alon
Does the project have an established view on non-ASCII names in
sources or docs?
AFAICS [1], the name of the algorithm may be Ryū.
-Chap
[1] https://dl.acm.org/citation.cfm?id=3192369
Rebased this patch onto current master. No functional changes; just
fixed up the copyright dates and a couple of stray missing UINT64CONSTs.
Regression tests still fail because how to fix them depends on the
issues below. Likewise docs are not changed yet for the same reason.
Decisions that need
> "Andres" == Andres Freund writes:
>> Is this a path we really want to go down? I'm not convinced the
>> cost/benefit ratio is attractive.
Andres> float->text conversion is one of the major bottlenecks when
Andres> backing up postgres, it's definitely a pain-point in practice.
Also an
> "Tom" == Tom Lane writes:
Tom> (Still, you might want to try to automate and document the coding
Tom> format conversion steps, along the line of what I've done recently
Tom> for our copy of tzcode.)
Working around our declaration-after-statement prohibition required
manually moving some
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> The maintenance track record of this github repo appears to span
> Tom> six months,
> The algorithm was only published six months ago.
Doesn't really affect my point: there's little reason to believe that
there will be an active upstrea
> "Tom" == Tom Lane writes:
Tom> The maintenance track record of this github repo appears to span
Tom> six months,
The algorithm was only published six months ago.
--
Andrew (irc:RhodiumToad)
Hi,
On 2018-12-14 13:47:53 -0500, Tom Lane wrote:
> Andres Freund writes:
> > It's been absorbed into MSVC's standard library and a bunch of other
> > projects, so there's certainly some other prominent adoption.
>
> If we think that's going on, maybe we should just sit tight till glibc
> absorb
Andres Freund writes:
> On 2018-12-14 13:25:29 -0500, Tom Lane wrote:
>> The maintenance track record of this github repo appears to span six
>> months, and it's now been about four months since the last commit.
>> It might be abandonware already.
> The last commit was a month ago, no? November 6
Hi,
On 2018-12-14 13:25:29 -0500, Tom Lane wrote:
> Our track record in borrowing code from "upstream" projects is pretty
> miserable: almost without exception, we've found ourselves stuck with
> maintaining such code ourselves after a few years. I don't see any
> reason to think that wouldn't be
Andrew Gierth writes:
> "Thomas" == Thomas Munro writes:
> Thomas> -1 for making superficial changes to code that we are
> Thomas> "vendoring", unless it is known to be dead/abandoned and we're
> Thomas> definitively forking it. It just makes it harder to track
> Thomas> upstream's bug fixes
> "Thomas" == Thomas Munro writes:
>>> Do we have any reason for the restriction beyond stylistic preference?
>> No. Robert and Tom were against allowing mixing declarations and
>> code, a few more against // comments. I don't quite agree with
>> either, but getting to the rest of C99 se
> "Andrew" == Andrew Gierth writes:
Andrew> And again to fix the windows build
And again to see if it actually compiles now...
--
Andrew (irc:RhodiumToad)
diff --git a/src/backend/utils/adt/float.c b/src/backend/utils/adt/float.c
index cf9327f885..24d41c2e89 100644
--- a/src/backend/util
On 2018-Dec-13, Andrew Gierth wrote:
> And again to fix the windows build - why does Mkvcbuild.pm have its own
> private copy of the file list for src/common?
I think at some point the Makefile parsing code was too stupid to deal
with the src/port Makefile, so it was hardcoded; later probably I
c
> "Andrew" == Andrew Gierth writes:
Andrew> This code in particular was very heavily into using mixed
Andrew> declarations and code throughout. Removing those was moderately
Andrew> painful.
Andrew> And it turns out I missed one, sigh.
Andrew> Updated patch.
And again to fix the windo
On Fri, Dec 14, 2018 at 8:00 AM Andres Freund wrote:
> Hi,
>
> On 2018-12-13 20:53:23 +, Andrew Gierth wrote:
> > > "Andres" == Andres Freund writes:
> >
> > >> This code in particular was very heavily into using mixed
> > >> declarations and code throughout. Removing those was moderate
> "Andrew" == Andrew Gierth writes:
Andrew> This code in particular was very heavily into using mixed
Andrew> declarations and code throughout. Removing those was moderately
Andrew> painful.
Andrew> And it turns out I missed one, sigh.
Updated patch.
--
Andrew (irc:RhodiumToad)
diff
> "Andrew" == Andrew Gierth writes:
Andrew> This code in particular was very heavily into using mixed
Andrew> declarations and code throughout. Removing those was moderately
Andrew> painful.
And it turns out I missed one, sigh.
--
Andrew (irc:RhodiumToad)
Hi,
On 2018-12-13 20:53:23 +, Andrew Gierth wrote:
> > "Andres" == Andres Freund writes:
>
> >> This code in particular was very heavily into using mixed
> >> declarations and code throughout. Removing those was moderately
> >> painful.
>
> Andres> I wonder if we should instead rela
> "Andres" == Andres Freund writes:
>> This code in particular was very heavily into using mixed
>> declarations and code throughout. Removing those was moderately
>> painful.
Andres> I wonder if we should instead relax those restriction for the
Andres> largely foreign pieces of code?
Hi,
On 2018-12-13 20:23:51 +, Andrew Gierth wrote:
> > "Andres" == Andres Freund writes:
>
> >> From the upstream, I've taken only specific files which are
> >> Boost-licensed, removed code not of interest to us, removed
> >> C99-isms, applied project style for things like type names
> "Andres" == Andres Freund writes:
>> From the upstream, I've taken only specific files which are
>> Boost-licensed, removed code not of interest to us, removed
>> C99-isms, applied project style for things like type names and use
>> of INT64CONST, removed some ad-hoc configuration #ifs
Hi,
On 2018-12-13 19:41:55 +, Andrew Gierth wrote:
> This is a mostly cleaned-up version of the test patch I posted
> previously for floating-point output using the Ryu algorithm.
Nice!
> From the upstream, I've taken only specific files which are
> Boost-licensed, removed code not of inter
This is a mostly cleaned-up version of the test patch I posted
previously for floating-point output using the Ryu algorithm.
Upstream source: github.com/ulfjack/ryu/ryu at commit 795c8b57a
>From the upstream, I've taken only specific files which are
Boost-licensed, removed code not of interest to
78 matches
Mail list logo
