Re: BUG #17390: Function, to_date() -- unexpected values and a request

"David G. Johnston" <david.g.johnston@gmail.com> writes:
> Pretend to_date doesn’t exist and just write a function that checks for
> valid inputs via RegEx and then parse it.  Maybe some day someone will
> develop a new conversion function that has considerably stricter, and
> self-defined, behavior (but given that to_date is basically “close enough
> to get the job done” I’m not optimistic).  Until then, protect yourself.

There are various things going on here:

* To the extent that to_date() has an accepted charter, it's "work
like the Oracle function of the same name".  Thus, arguments like
"it'd be better for my use-case if it did X" are basically not going
to find any traction.  Arguments like "Oracle's to_date() does X,
so we should too" have a better chance.  Unfortunately, most of us
lack access to an Oracle instance, making it hard to investigate
such details.

* The formatting.c code has recently been hacked up to also support
jsonpath datetime conversions, meaning that there's a second source
of truth involved; any proposed change would need to also be measured
against whether it moves us closer to or further away from the relevant
jsonpath standard.  That's another hard-to-get-hold-of reference, and
I'm not sure how detailed its answers would be anyway.

* There's also a fairly strong argument for maintaining backwards
compatibility, even if the existing behavior is arguably wrong per
the above points.

* formatting.c is an ill-documented, unmaintainable mess that nobody
is eager to touch.  (The original author is long gone.)

These things combine to encourage leaving it at the status quo.
Somebody who was really motivated and willing to get their hands
dirty could perhaps get something done, but I don't think any of
the current crop of hackers are very interested.

            regards, tom lane