Tom> In the context of interval literals it's probably
Tom> unnecessary, but that's not the only thing to worry about.
Tom> In particular we have to consider the behavior of the input
Tom> and output routines for cases like COPY. I think it would be
Tom> really bad to reject '1 hour 10 minutes' as data input into
Tom> an interval field just because it has an ISO qualifier.
Hmm, but COPY is non-standard, so I'd be happy that it insisted on
postgres interval syntax. ANSI interval syntax is confusing in this
context, precisely because there is nowhere to actually put an
'interval qualifier' in the literals. Otherwise the fact that
ALTERing a table to add a constraint will completely change the
semantices of the COPYing data into the table worries me.
I don't think that conceptually the qualifier on an interval type is
really the same thing as the qualifier on an interval literal.
Tom> Also, I would personally prefer to see the output from an
Tom> interval field remain in the Postgres format
Seconded. But that's fine, too, I think. Pretty much everything
about an interactive SQL session is implementation defined.
If people are using embedded SQL, or one of the libraries, than isn't
it a non-issue?
-roy
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
