Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Jun 23, 2016 at 1:40 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> At the very least I'd want to see a thought-through proposal that
>> addresses all three of these interrelated points:
>>
>> * what should a space in the format match
>> * what should a non-space, non-format-code character in the format match
>> * how should we handle fields that are not exactly the width suggested
>> by the format
> I'm not averse to some further study of those issues, and I think the
> first two are closely related. The third one strikes me as a somewhat
> separate consideration that doesn't need to be addressed by the same
> patch.
If you think those issues are not interrelated, you have not thought
about it carefully enough.
As an example, what we can do to handle not-expected-width fields is
very different if the format is "DDMMYY" versus if it is "DD-MM-YY".
In the first case we have little choice but to believe that each
field is exactly two digits wide. In the second case, depending on
how we decide to define matching of "-", we might be able to allow
the field widths to vary so that they're effectively "whatever is
between the dashes". But that would require insisting that "-"
match a "-", or at least a non-alphanumeric, which is not how it
behaves today.
I don't want to twiddle these behaviors in 9.6 and then again next year.
regards, tom lane
