From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Thom Brown <thom(at)linux(dot)com> |
Cc: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, PGSQL Mailing List <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: White space affecting parsing of range values |
Date: | 2020-05-06 16:33:33 |
Message-ID: | 15749.1588782813@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Thom Brown <thom(at)linux(dot)com> writes:
> I guess I should read the docs more carefully. Shouldn't this be
> insignificant for a numeric value?
That would require the range code to know whether the subtype considers
whitespace significant (or perhaps more usefully, whether an all-spaces
input is valid). We've stayed away from requiring range_in to have any
type-specific knowledge of that sort.
Still, you could argue that the rule ought to be "an empty or all-blank
value must be quoted to distinguish it from an omitted bound" rather than
"an empty value must be quoted to distinguish it from an omitted bound".
I'm not sure if we could get away with redefining that at this point,
though. It looks like range_out quotes such values already, so maybe a
change wouldn't be totally catastrophic (in the sense of breaking dump
files). But I still suspect there would be more people unhappy than
happy.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Thom Brown | 2020-05-06 16:51:29 | Re: White space affecting parsing of range values |
Previous Message | Adrian Klaver | 2020-05-06 16:30:07 | Re: White space affecting parsing of range values |