Skip site navigation (1) Skip section navigation (2)

Re: BUG #1517: SQL interval syntax is accepted by the parser,

From: Roy Badami <roy(at)gnomon(dot)org(dot)uk>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Roy Badami <roy(at)gnomon(dot)org(dot)uk>,Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #1517: SQL interval syntax is accepted by the parser,
Date: 2005-03-23 23:26:48
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
    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?


In response to


pgsql-bugs by date

Next:From: Peter EisentrautDate: 2005-03-23 23:28:28
Subject: Re: BUG #1517: SQL interval syntax is accepted by the parser,
Previous:From: Roy BadamiDate: 2005-03-23 23:19:07
Subject: Re: BUG #1518: Conversions to (undocumented) SQL year-month

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group