Re: [COMMITTERS] pgsql-server/ oc/src/sgml/datatype.sgml

On Sat, 20 Dec 2003, Bruce Momjian wrote:
>Tom Lane wrote:
>>This is a horrid, horrid idea. Datestyle is already a complete mess
>> ...
>>Please revert that part of the patch and instead invent a new GUC
>>variable that's specifically for interval formatting.
>
> OK, I have backed out the patch. [...]

Short summary...

Before I try this, through email someone suggested yet a
different idea...

Would formatting functions for intervals such as...
to_iso8601basic_char(interval) -- return ISO-8601 basic fmt interval
to_iso8601basic_char(timestamp) -- return ISO-8601 basic fmt date/time
would be better than a new GUC variable?

Longer...

Tom Lane wrote:
>
> This is a horrid, horrid idea. Datestyle is already a complete mess
> because it is being used to control several things; it should have
> been two or possibly three GUC variables not one. Sticking in yet
> another behavior is just not acceptable IMHO, especially when it's
> defined as non-orthogonally as that.
>
> Please revert that part of the patch and instead invent a new GUC
> variable that's specifically for interval formatting.

First I just wanted to say how it ended up using datestyle...

In the earlier discussion when Andrew asked about a way of outputting
ISO-8601 Basic Format time intervals, the use of datestyle came up,
and noone objected to the use of datestyle at that point.

... Tom was suggesting:
http://archives.postgresql.org/pgsql-patches/2003-09/msg00122.php
TL>
TL> Perhaps call it "compact" or "terse" datestyle?

... and Peter suggested:
http://archives.postgresql.org/pgsql-patches/2003-09/msg00129.php
PE>
PE> iso8601
PE>
PE> Keep in mind that SQL itself is also a kind of ISO, so being
PE> more specific is useful.

Regarding the non-orthogonality, I was suspecting that most
applications that use ISO-8601 Basic Formats would use them
consistently for dates (19990131) and intervals (P1Y1M).
But I do see your point and agree this isn't a good solution.

If the developers would like separate GUC variables for
formatting dates vs intervals, I would be happy to do so.
On the other hand, if the idea of outputting ISO-8601
intervals is likely to be rejected anyway, I'd be happy
to not do it too. :-)

Or, how would people feel instead about formatting functions
to produce the various ISO-8601 formats?
to_iso8601basic_char(timestamp)
to_iso8601basic_char(interval)
I think this could be especially useful since the docs:
http://developer.postgresql.org/docs/postgres/functions-formatting.html
say that "to_char(interval, text)" is being deprecated,
meaning that converting intervals to formats other systems
accept will soon become harder.

Personally, though, I'm most interested in the input side.

I have an application that uses ISO-8601 Basic Format
for all it's time information (Dates, Times, and Intervals), and
wanted to load this information into PostgreSQL. I was happy
to see that Dates and Times loaded.

Unfortunately intervals did not.

A quick investigation showed that PostgreSQL currently has an
undocumented shorthand is similar but frustratingly different
from ISO-8601:
(i.e. '1Y1M'::interval means '1 year 1 minute' to PostgreSQL 7.3X,
while 'P1Y1M' means '1 year 1 month' to ISO-8601).
Even if nothing is done to the output side, allowing inputting
of such intervals would benefit me.

Would the developers prefer a patch allowing the inputting
of such intervals, and not support outputting at all?

> BTW, I can tell without looking that the patch is deficient in
> documentation; if it has effects on GUC variables, why is there no
> mod in runtime.sgml?

Point well taken. Before I submit any future patches I will try
to be more careful in this regard.

Ron

PS: The spec I'm referring to is ISO-8601... Section 5.5.4.2
http://www.webaugur.com/bibliotheca/standards/iso8601/154N362/index-25.html