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

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