Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I see this as a feature addition, because right now, in 2003, there is
> no way to enter a current date with a leading year using only two digits.
How can you say that, when there is a regression test that proves it
works (and always has worked)?
>> There are presently only two input DateStyles ('US' and 'European') but
>> it would be trivial to add a third to accept yy-mm-dd. We'd only need
>> to figure out what to call it. I'm tempted to just call it 'YMD' and
>> provide 'DMY' and 'MDY' as alternative names for 'US' and 'European'.
> Now, that is an interesting idea, and I wonder if they aren't better
> than US and European (and German), because they are more general.
I'm envisioning these as determining the input interpretation only.
The output formatting choices are a distinct set. (It was a bad idea to
overload DateStyle to contain two separate settings, but we're probably
stuck with that for now.) But yes, I could easily be talked into making
these names be the standard ones. Right now would be the time to do it,
since we're already changing the output format of "SHOW DATESTYLE"; if
we wait a cycle then we'll be churning that API twice in a row.
> Is this something we want to do in feature freeze?
I think it's a necessary part of the already-proposed patch to tighten
input date interpretation. Now personally I'd be quite happy to put off
that whole affair for 7.5, because I don't think it's been thought
through adequately. But if you want to complete that open item in this
cycle, then I think we have to follow it out to the logical conclusions.
You can't arbitrarily decide to remove functionality and not put a
substitute in place just because we're past feature freeze. (A freeze
extends to not removing stuff, as well as not adding stuff, IMHO.)
regards, tom lane