ParseDateTime in src/backend/utils/adt/datetime.c

Started by Vladimir Svedovover 7 years ago2 messages
#1Vladimir Svedov
vodevsh@gmail.com

Hi guys,
https://stackoverflow.com/questions/50153122/how-come-this-postgres-query-is-working
Above guys are surprised by "ignore other punctuation but use as delimiter"
part.
Do you think this should be mentioned in docs?
E.g.
https://www.postgresql.org/docs/current/static/functions-formatting.html
docs have very thorough explanation on what is skipped and what parsed.

I believe at least interval '1^minute' equality to interval '1 minute' or
other short comment would make it clear.

Sorry if Iwrote to a wrong list. Maybe I should write to
pgsql-docs@lists.postgresql.org instead? please point me If I should.

Regards

#2Bruce Momjian
bruce@momjian.us
In reply to: Vladimir Svedov (#1)
Re: ParseDateTime in src/backend/utils/adt/datetime.c

On Thu, May 3, 2018 at 12:21:45PM +0100, Vladimir Svedov wrote:

Hi guys,
https://stackoverflow.com/questions/50153122/
how-come-this-postgres-query-is-working
Above guys are surprised by "ignore other punctuation but use as delimiter"
part.
Do you think this should be mentioned in docs?
E.g.�https://www.postgresql.org/docs/current/static/functions-formatting.html
docs have very thorough explanation on what is skipped and what parsed.

I believe at least�interval '1^minute' equality to�interval '1 minute' or other
short comment would make it clear.

Sorry if Iwrote to a wrong list. Maybe I should write to�
pgsql-docs@lists.postgresql.org instead? please point me If I should.

Hmm, that's interesting:

SELECT interval '1^minute';
interval
----------
00:01:00

to_number() was just changed in Postgres 11 to properly ignore
puntuation:

Prevent to_number() from consuming characters when the template
separator does not match (Oliver Ford)

Specifically, SELECT to_number('1234', '9,999') used to return 134.
It will now return 1234. L and TH now only consume characters
that are not digits, positive/negative signs, decimal points,
and commas.

so I think we are consistent in ignoring invalid input characters so I
would we would change it.

I am not sure adding documentation would really help much.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +