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?


  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:
  TL> Perhaps call it "compact" or "terse" datestyle?

  ... and Peter suggested:
  PE> iso8601
  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?
 I think this could be especially useful since the docs:
 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.


PS: The spec I'm referring to is ISO-8601... Section

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Reply via email to