pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
INTERVAL SECOND limited to 59 seconds?
8+ messages / 4 participants
[nested] [flat]

* INTERVAL SECOND limited to 59 seconds?
@ 2009-05-19 08:39  Sebastien FLAESCH <sf@4js.com>
  0 siblings, 2 replies; 8+ messages in thread

From: Sebastien FLAESCH @ 2009-05-19 08:39 UTC (permalink / raw)
  To: pgsql-general@postgresql.org; +Cc: mmoncure@gmail.com

Hello,

Can someone explain this:

test1=> create table t1 ( k int, i interval second );
CREATE TABLE
test1=> insert into t1 values ( 1, '-67 seconds' );
INSERT 0 1
test1=> insert into t1 values ( 2, '999 seconds' );
INSERT 0 1
test1=> select * from t1;
  k |     i
---+-----------
  1 | -00:00:07
  2 | 00:00:39
(2 rows)

I would expect that an INTERVAL SECOND can store more that 59 seconds.

Same question for INTERVAL MINUTE TO SECOND (but here we get an overflow error):

test1=> create table t2 ( k int, i interval minute to second );
CREATE TABLE
test1=> insert into t2 values ( 2, '9999:59' );
ERROR:  interval field value out of range: "9999:59"
LINE 1: insert into t2 values ( 2, '9999:59' );
                                    ^
test1=> insert into t2 values ( 2, '999:59' );
ERROR:  interval field value out of range: "999:59"
LINE 1: insert into t2 values ( 2, '999:59' );
                                    ^
test1=> insert into t2 values ( 2, '99:59' );
ERROR:  interval field value out of range: "99:59"
LINE 1: insert into t2 values ( 2, '99:59' );
                                    ^
test1=> insert into t2 values ( 1, '59:59' );
INSERT 0 1

test1=> insert into t2 values ( 2, '-123:59' );
INSERT 0 1

test1=> select * from t2;
  k |     i
---+-----------
  1 | 00:59:59
  2 | -00:59:00
(2 rows)


It's ok when using DAYs:

test1=> create table t3 ( k int, i interval day to second );
CREATE TABLE
test1=> insert into t3 values ( 1, '-9999 18:59:59' );
INSERT 0 1
test1=> insert into t3 values ( 1, '9999999 18:59:59' );
INSERT 0 1
test1=> select * from t3;
  k |           i
---+-----------------------
  1 | -9999 days +18:59:59
  1 | 9999999 days 18:59:59
(2 rows)




Thanks a lot!
Seb
/*
Version:    8.4.beta1
Created by: sf@4js.com

Problem with INTERVAL input format
----------------------------------

After executing this program, 2 rows are present in the table.
Only the first has the expected values...

Why does the second insert fail to insert "123 11" in INTERVAL DAY TO HOUR?
Diagnostic info:
  SQL State: 22007
  Message  : invalid input syntax for type interval: " 123 11"

Why does the third row show "00:00:00" in first INTERVAL YEAR column?

[sf@fox problems]$ psql test1 -U pgsuser
psql (8.4beta1)
Type "help" for help.

test1=> select * from t1;
 k |      i1      |        i2
---+--------------+-------------------
 1 | -12345 years | 123 days 11:00:00
 3 | 00:00:00     | 123 days 11:00:00
(2 rows)

When inserting rows with psql, the format used by the C program are supported:

test1=> insert into t1 values ( 4, '-12345', '123 11' );
INSERT 0 1
test1=> select * from t1 where k=4;
 k |      i1      |        i2
---+--------------+-------------------
 4 | -12345 years | 123 days 11:00:00
(1 row)

So what am I doing wrong here?

*/

#include <stdio.h>
#include <libpq-fe.h>

static int checkResult(PGresult * r)
{
    if (r == NULL)
        return 0;
    switch (PQresultStatus(r)) {
    case PGRES_COMMAND_OK:
    case PGRES_TUPLES_OK:
        return 1;
    default:
        return 0;
    }
}

static void getErrorInfo(PGresult * r)
{
    if (r == NULL)
       return;
    fprintf(stderr, "Diagnostic info:\n");
    fprintf(stderr, "  SQL State: %s\n", PQresultErrorField(r, PG_DIAG_SQLSTATE));
    fprintf(stderr, "  Message  : %s\n", PQresultErrorField(r, PG_DIAG_MESSAGE_PRIMARY));
}

int main(int argc, char **argv)
{
    PGresult *r;
    PGconn *c;
    Oid paramTypes[10];
    const char *paramValues[10];

    fprintf(stdout,"++ Connecting...\n");
    c = PQconnectdb("dbname='test1' user='pgsuser' password='fourjs'");
    if (c == NULL) {
        fprintf(stderr,">> Could not connect.\n");
        exit(1);
    }

    fprintf(stdout,"++ Creating table t1 ...\n");
    r = PQexec(c, "DROP TABLE t1");
    PQclear(r);
    r = PQexec(c, "CREATE TABLE t1 ( k INT, i1 INTERVAL YEAR, i2 INTERVAL DAY TO HOUR)");
    if (!checkResult(r)) {
        fprintf(stderr,">> Could not create table 1.\n");
        getErrorInfo(r);
        exit(1);
    }
    PQclear(r);

    fprintf(stdout,"++ Preparing INSERT ...\n");
    paramTypes[0] = 23;     /* INT4 */
    paramTypes[1] = 1186;   /* INTERVAL */
    paramTypes[2] = 1186;   /* INTERVAL */
    r = PQprepare(c, "s1",
                  "INSERT INTO t1 VALUES ( $1, $2, $3 )",
                  3, (const Oid *) paramTypes);
    if (!checkResult(r)) {
        fprintf(stderr,">> Could not prepare stmt 1.\n");
        getErrorInfo(r);
        exit(1);
    }
    PQclear(r);

    /* This is working */
    fprintf(stdout,"++ Executing INSERT (1) ...\n");
    paramValues[0] = "1";
    paramValues[1] = "-12345 years";
    paramValues[2] = " 123 11:00";
    r = PQexecPrepared(c, "s1", 3, paramValues, NULL, NULL, 0);
    if (!checkResult(r)) {
        fprintf(stderr,">> Could not exec stmt 1.\n");
        getErrorInfo(r);
        exit(1);
    }
    PQclear(r);

    /* This is NOT working */
    fprintf(stdout,"++ Executing INSERT (2) ...\n");
    paramValues[0] = "2";
    paramValues[1] = "-12345";
    paramValues[2] = " 123 11";
    r = PQexecPrepared(c, "s1", 3, paramValues, NULL, NULL, 0);
    if (!checkResult(r)) {
        fprintf(stderr,">> Could not exec stmt 2.\n");
        getErrorInfo(r);
        /*exit(1);*/
    }
    PQclear(r);

    /* This is NOT working */
    fprintf(stdout,"++ Executing INSERT (3) ...\n");
    paramValues[0] = "3";
    paramValues[1] = "-12345";
    paramValues[2] = " 123 11:00";
    r = PQexecPrepared(c, "s1", 3, paramValues, NULL, NULL, 0);
    if (!checkResult(r)) {
        fprintf(stderr,">> Could not exec stmt 3.\n");
        getErrorInfo(r);
        exit(1);
    }
    PQclear(r);

    PQfinish(c);
}

Attachments:

  [text/plain] libpqtest1.c (3.8K, ../../4A127038.3010103@4js.com/2-libpqtest1.c)
  download | inline:
/*
Version:    8.4.beta1
Created by: sf@4js.com

Problem with INTERVAL input format
----------------------------------

After executing this program, 2 rows are present in the table.
Only the first has the expected values...

Why does the second insert fail to insert "123 11" in INTERVAL DAY TO HOUR?
Diagnostic info:
  SQL State: 22007
  Message  : invalid input syntax for type interval: " 123 11"

Why does the third row show "00:00:00" in first INTERVAL YEAR column?

[sf@fox problems]$ psql test1 -U pgsuser
psql (8.4beta1)
Type "help" for help.

test1=> select * from t1;
 k |      i1      |        i2
---+--------------+-------------------
 1 | -12345 years | 123 days 11:00:00
 3 | 00:00:00     | 123 days 11:00:00
(2 rows)

When inserting rows with psql, the format used by the C program are supported:

test1=> insert into t1 values ( 4, '-12345', '123 11' );
INSERT 0 1
test1=> select * from t1 where k=4;
 k |      i1      |        i2
---+--------------+-------------------
 4 | -12345 years | 123 days 11:00:00
(1 row)

So what am I doing wrong here?

*/

#include <stdio.h>
#include <libpq-fe.h>

static int checkResult(PGresult * r)
{
    if (r == NULL)
        return 0;
    switch (PQresultStatus(r)) {
    case PGRES_COMMAND_OK:
    case PGRES_TUPLES_OK:
        return 1;
    default:
        return 0;
    }
}

static void getErrorInfo(PGresult * r)
{
    if (r == NULL)
       return;
    fprintf(stderr, "Diagnostic info:\n");
    fprintf(stderr, "  SQL State: %s\n", PQresultErrorField(r, PG_DIAG_SQLSTATE));
    fprintf(stderr, "  Message  : %s\n", PQresultErrorField(r, PG_DIAG_MESSAGE_PRIMARY));
}

int main(int argc, char **argv)
{
    PGresult *r;
    PGconn *c;
    Oid paramTypes[10];
    const char *paramValues[10];

    fprintf(stdout,"++ Connecting...\n");
    c = PQconnectdb("dbname='test1' user='pgsuser' password='fourjs'");
    if (c == NULL) {
        fprintf(stderr,">> Could not connect.\n");
        exit(1);
    }

    fprintf(stdout,"++ Creating table t1 ...\n");
    r = PQexec(c, "DROP TABLE t1");
    PQclear(r);
    r = PQexec(c, "CREATE TABLE t1 ( k INT, i1 INTERVAL YEAR, i2 INTERVAL DAY TO HOUR)");
    if (!checkResult(r)) {
        fprintf(stderr,">> Could not create table 1.\n");
        getErrorInfo(r);
        exit(1);
    }
    PQclear(r);

    fprintf(stdout,"++ Preparing INSERT ...\n");
    paramTypes[0] = 23;     /* INT4 */
    paramTypes[1] = 1186;   /* INTERVAL */
    paramTypes[2] = 1186;   /* INTERVAL */
    r = PQprepare(c, "s1",
                  "INSERT INTO t1 VALUES ( $1, $2, $3 )",
                  3, (const Oid *) paramTypes);
    if (!checkResult(r)) {
        fprintf(stderr,">> Could not prepare stmt 1.\n");
        getErrorInfo(r);
        exit(1);
    }
    PQclear(r);

    /* This is working */
    fprintf(stdout,"++ Executing INSERT (1) ...\n");
    paramValues[0] = "1";
    paramValues[1] = "-12345 years";
    paramValues[2] = " 123 11:00";
    r = PQexecPrepared(c, "s1", 3, paramValues, NULL, NULL, 0);
    if (!checkResult(r)) {
        fprintf(stderr,">> Could not exec stmt 1.\n");
        getErrorInfo(r);
        exit(1);
    }
    PQclear(r);

    /* This is NOT working */
    fprintf(stdout,"++ Executing INSERT (2) ...\n");
    paramValues[0] = "2";
    paramValues[1] = "-12345";
    paramValues[2] = " 123 11";
    r = PQexecPrepared(c, "s1", 3, paramValues, NULL, NULL, 0);
    if (!checkResult(r)) {
        fprintf(stderr,">> Could not exec stmt 2.\n");
        getErrorInfo(r);
        /*exit(1);*/
    }
    PQclear(r);

    /* This is NOT working */
    fprintf(stdout,"++ Executing INSERT (3) ...\n");
    paramValues[0] = "3";
    paramValues[1] = "-12345";
    paramValues[2] = " 123 11:00";
    r = PQexecPrepared(c, "s1", 3, paramValues, NULL, NULL, 0);
    if (!checkResult(r)) {
        fprintf(stderr,">> Could not exec stmt 3.\n");
        getErrorInfo(r);
        exit(1);
    }
    PQclear(r);

    PQfinish(c);
}

^ permalink  raw  reply  [nested|flat] 8+ messages in thread

* Re: INTERVAL SECOND limited to 59 seconds?
@ 2009-05-19 08:53  Richard Huxton <dev@archonet.com>
  parent: Sebastien FLAESCH <sf@4js.com>
  1 sibling, 1 reply; 8+ messages in thread

From: Richard Huxton @ 2009-05-19 08:53 UTC (permalink / raw)
  To: Sebastien FLAESCH <sf@4js.com>; +Cc: pgsql-general@postgresql.org; mmoncure@gmail.com

Sebastien FLAESCH wrote:
> Hello,
> 
> Can someone explain this:
> 
> test1=> create table t1 ( k int, i interval second );
> CREATE TABLE
> test1=> insert into t1 values ( 1, '-67 seconds' );
> INSERT 0 1
> test1=> insert into t1 values ( 2, '999 seconds' );
> INSERT 0 1
> test1=> select * from t1;
>  k |     i
> ---+-----------
>  1 | -00:00:07
>  2 | 00:00:39
> (2 rows)
> 
> I would expect that an INTERVAL SECOND can store more that 59 seconds.

I didn't even know we had an "interval second" type. It's not entirely 
clear to me what such a value means. Anyway - what's happening is that 
it's going through "interval" first. So - '180 seconds' will yield 
'00:03:00' and the seconds part of that is zero.

The question I suppose is whether that's correct or not. An interval can 
clearly store periods longer than 59 seconds. It's reasonable to ask for 
an interval to be displayed as "61 seconds". If "interval second" means 
the seconds-only part of an interval though, then it's doing the right 
thing.

-- 
   Richard Huxton
   Archonet Ltd



^ permalink  raw  reply  [nested|flat] 8+ messages in thread

* Re: INTERVAL SECOND limited to 59 seconds?
@ 2009-05-19 09:17  Sebastien FLAESCH <sf@4js.com>
  parent: Richard Huxton <dev@archonet.com>
  0 siblings, 1 reply; 8+ messages in thread

From: Sebastien FLAESCH @ 2009-05-19 09:17 UTC (permalink / raw)
  To: pgsql-general@postgresql.org

I think it should be clarified in the documentation...

Actually I would like to use this new INTERVAL type to store IBM/Informix INTERVALs,
which can actually be used like this with DATETIME types:

 > create table t1 (
 >     k int,
 >     dt1 datetime hour to minute,
 >     dt2 datetime hour to minute,
 >     i interval hour(5) to minute );
Table created.

 > insert into t1 values ( 1, '14:45', '05:10', '-145:10' );
1 row(s) inserted.

 > select dt1 - dt2 from t1;
(expression)
   9:35                        <- INTERVAL expression
1 row(s) retrieved.

 > select 15 * ( dt1 - dt2 ) from t1;
(expression)
        143:45                        <- INTERVAL expression
1 row(s) retrieved.



The PostgreSQL documentation says:

The interval type has an additional option, which is to restrict the set of stored
fields by writing one of these phrases:

     YEAR
     MONTH
     DAY
     HOUR
     MINUTE
     SECOND
     YEAR TO MONTH
     DAY TO HOUR
     DAY TO MINUTE
     DAY TO SECOND
     HOUR TO MINUTE
     MINUTE TO SECOND

Does that mean that the [field] option of the INTERVAL type is just there to save
storage space?

Confusing...

Seb

Richard Huxton wrote:
> Sebastien FLAESCH wrote:
>> Hello,
>>
>> Can someone explain this:
>>
>> test1=> create table t1 ( k int, i interval second );
>> CREATE TABLE
>> test1=> insert into t1 values ( 1, '-67 seconds' );
>> INSERT 0 1
>> test1=> insert into t1 values ( 2, '999 seconds' );
>> INSERT 0 1
>> test1=> select * from t1;
>>  k |     i
>> ---+-----------
>>  1 | -00:00:07
>>  2 | 00:00:39
>> (2 rows)
>>
>> I would expect that an INTERVAL SECOND can store more that 59 seconds.
> 
> I didn't even know we had an "interval second" type. It's not entirely 
> clear to me what such a value means. Anyway - what's happening is that 
> it's going through "interval" first. So - '180 seconds' will yield 
> '00:03:00' and the seconds part of that is zero.
> 
> The question I suppose is whether that's correct or not. An interval can 
> clearly store periods longer than 59 seconds. It's reasonable to ask for 
> an interval to be displayed as "61 seconds". If "interval second" means 
> the seconds-only part of an interval though, then it's doing the right 
> thing.
> 




^ permalink  raw  reply  [nested|flat] 8+ messages in thread

* Re: INTERVAL SECOND limited to 59 seconds?
@ 2009-05-19 09:30  Richard Huxton <dev@archonet.com>
  parent: Sebastien FLAESCH <sf@4js.com>
  0 siblings, 2 replies; 8+ messages in thread

From: Richard Huxton @ 2009-05-19 09:30 UTC (permalink / raw)
  To: Sebastien FLAESCH <sf@4js.com>; +Cc: pgsql-general@postgresql.org

Sebastien FLAESCH wrote:
> I think it should be clarified in the documentation...

Please don't top-quote. And yes, I think you're right.

Hmm a quick google for: [sql "interval second"] suggests that it's not 
the right thing. I see some mention of 2 digit precision for a leading 
field, but no "clipping".

Looking at the manuals and indeed a quick \dT I don't see "interval 
second" listed as a separate type though. A bit of exploring in 
pg_attribute with a test table suggests it's just using "interval" with 
a type modifier. Which you seem to confirm from the docs:

 > The PostgreSQL documentation says:
 >
 > The interval type has an additional option, which is to restrict the set
 > of stored
 > fields by writing one of these phrases:
 >
 >     YEAR
 >     MONTH
...
 > Does that mean that the [field] option of the INTERVAL type is just
 > there to save
 > storage space?

My trusty copy of the 8.3 source suggests that AdjustIntervalForTypmod() 
is the function we're interested in and it lives in 
backend/utils/adt/timestamp.c - it looks like it just zeroes out the 
fields you aren't interested in. No space saving.

So - not a bug, but perhaps not the behaviour you would expect.

> Actually I would like to use this new INTERVAL type to store 
> IBM/Informix INTERVALs,
> which can actually be used like this with DATETIME types:
> 
>  > create table t1 (
>  >     k int,
>  >     dt1 datetime hour to minute,
>  >     dt2 datetime hour to minute,
>  >     i interval hour(5) to minute );
> Table created.
> 
>  > insert into t1 values ( 1, '14:45', '05:10', '-145:10' );
> 1 row(s) inserted.
> 
>  > select dt1 - dt2 from t1;
> (expression)
>   9:35                        <- INTERVAL expression

  SELECT ('14:45'::time - '05:10'::time);
  ?column?
----------
  09:35:00
(1 row)


>  > select 15 * ( dt1 - dt2 ) from t1;
> (expression)
>        143:45                        <- INTERVAL expressio

=> SELECT 15 * ('14:45'::time - '05:10'::time);
  ?column?
-----------
  143:45:00
(1 row)

If you can live with the zero seconds appearing, it should all just 
work*. Other than formatting as text, I don't know of a way to suppress 
them though.

* Depending on whether you need to round up if you ever get odd seconds etc.

-- 
   Richard Huxton
   Archonet Ltd



^ permalink  raw  reply  [nested|flat] 8+ messages in thread

* Re: INTERVAL SECOND limited to 59 seconds?
@ 2009-05-19 09:53  Sebastien FLAESCH <sf@4js.com>
  parent: Richard Huxton <dev@archonet.com>
  1 sibling, 1 reply; 8+ messages in thread

From: Sebastien FLAESCH @ 2009-05-19 09:53 UTC (permalink / raw)
  To: pgsql-general@postgresql.org

Actually it's not limited to the usage of INTERVAL SECOND, I am writing
a PostgreSQL driver for our 4GL virtual machine...

I need to store all possible Informix INTERVAL types such as:

    INTERVAL MONTH(8) TO MONTH
    INTERVAL DAY(8) TO MINUTE
    INTERVAL SECOND TO FRACTION(5)
    ... etc ...

...

If PostgreSQL is not able to store months > 11, hours > 23 and minutes
or seconds > 59, it looks like I will need to deal with PostgreSQL's

    INTERVAL YEAR TO MONTH
    INTERVAL DAY TO SECOND(5)

... and make conversions, to store all possible Informix INTERVALs...

Seb




^ permalink  raw  reply  [nested|flat] 8+ messages in thread

* Re: INTERVAL SECOND limited to 59 seconds?
@ 2009-05-19 09:57  Richard Huxton <dev@archonet.com>
  parent: Richard Huxton <dev@archonet.com>
  1 sibling, 0 replies; 8+ messages in thread

From: Richard Huxton @ 2009-05-19 09:57 UTC (permalink / raw)
  To: Sebastien FLAESCH <sf@4js.com>; PgSql General <pgsql-general@postgresql.org>

Sebastien FLAESCH wrote:
> Actually it's not limited to the usage of INTERVAL SECOND, I am writing
> a PostgreSQL driver for our 4GL virtual machine...
> 
> I need to store all possible Informix INTERVAL types such as:
> 
>    INTERVAL MONTH(8) TO MONTH
>    INTERVAL DAY(8) TO MINUTE
>    INTERVAL SECOND TO FRACTION(5)
>    ... etc ...
> 
> ...
> 
> If PostgreSQL is not able to store months > 11, hours > 23 and minutes
> or seconds > 59

Well, it's not storage it's formatting. Doesn't make any difference to 
your problem though.

 >, it looks like I will need to deal with PostgreSQL's
> 
>    INTERVAL YEAR TO MONTH
>    INTERVAL DAY TO SECOND(5)
> 
> ... and make conversions, to store all possible Informix INTERVALs...

If you know a little "C" you could build some custom types to match your 
needs. It should just be a matter of applying the correct formatting as 
a wrapper around the existing "interval" type.

-- 
   Richard Huxton
   Archonet Ltd



^ permalink  raw  reply  [nested|flat] 8+ messages in thread

* Re: INTERVAL SECOND limited to 59 seconds?
@ 2009-05-20 06:42  Scott Bailey <artacus@comcast.net>
  parent: Sebastien FLAESCH <sf@4js.com>
  0 siblings, 0 replies; 8+ messages in thread

From: Scott Bailey @ 2009-05-20 06:42 UTC (permalink / raw)
  To: pgsql-general@postgresql.org

Sebastien FLAESCH wrote:
> Actually it's not limited to the usage of INTERVAL SECOND, I am writing
> a PostgreSQL driver for our 4GL virtual machine...
> 
> I need to store all possible Informix INTERVAL types such as:
> 
>    INTERVAL MONTH(8) TO MONTH
>    INTERVAL DAY(8) TO MINUTE
>    INTERVAL SECOND TO FRACTION(5)

In Postgres, you should just store it as an INTERVAL which (unlike some 
other RDBMS') has the ability to store ranges from fractional seconds to 
  thousands of years. Then if you need to output it in the above format, 
make a view that splits the actual interval into month, minute and 
fractional second pieces.



^ permalink  raw  reply  [nested|flat] 8+ messages in thread

* Re: INTERVAL SECOND limited to 59 seconds?
@ 2009-05-31 21:35  Tom Lane <tgl@sss.pgh.pa.us>
  parent: Sebastien FLAESCH <sf@4js.com>
  1 sibling, 0 replies; 8+ messages in thread

From: Tom Lane @ 2009-05-31 21:35 UTC (permalink / raw)
  To: Sebastien FLAESCH <sf@4js.com>; +Cc: pgsql-general@postgresql.org; mmoncure@gmail.com; pgsql-hackers

Sebastien FLAESCH <sf@4js.com> writes:
> I would expect that an INTERVAL SECOND can store more that 59 seconds.

I took a look into the SQL spec and I think that we do indeed have a
spec compliance issue here.  SQL99 section 4.7 saith

         Within a value of type interval, the first field is constrained
         only by the <interval leading field precision> of the associated
         <interval qualifier>. Table 8, "Valid values for fields in INTERVAL
         values", specifies the constraints on subsequent field values.
	 [ Table 8 says about what you'd expect, eg 0..23 for HOUR ]
         Values in interval fields other than SECOND are integers and have
         precision 2 when not the first field. SECOND, however, can be
         defined to have an <interval fractional seconds precision> that
         indicates the number of decimal digits maintained following the
         decimal point in the seconds value. When not the first field,
         SECOND has a precision of 2 places before the decimal point.

So in other words, "999 seconds" is a valid value for a field of type
INTERVAL SECOND, *and should come out the same way*, not as "00:16:39",
and certainly not as "00:00:39".

It might be a relatively easy fix to not truncate the input value
incorrectly.  I haven't looked, but I think we should look now, because
8.4 has already changed the behavior in this area and it would be good
not to change it twice.  The focus of the 8.4 work was to make sure that
we would correctly interpret the values of spec-compliant interval
literals, but this example shows we are not there yet.

We are fairly far away from being able to make it print out as the spec
would suggest, because interval_out simply doesn't have access to the
information that the field is constrained to be INTERVAL SECOND rather
than some other kind of interval.  We also have got no concept at all of
<interval leading field precision>, only of <interval fractional seconds
precision>, so constraining the leading field to only a certain number
of integral digits isn't possible either.  I don't foresee anything
getting done about either of those points for 8.4.

			regards, tom lane



^ permalink  raw  reply  [nested|flat] 8+ messages in thread


end of thread, other threads:[~2009-05-31 21:35 UTC | newest]

Thread overview: 8+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2009-05-19 08:39 INTERVAL SECOND limited to 59 seconds? Sebastien FLAESCH <sf@4js.com>
2009-05-19 08:53 ` Richard Huxton <dev@archonet.com>
2009-05-19 09:17   ` Sebastien FLAESCH <sf@4js.com>
2009-05-19 09:30     ` Richard Huxton <dev@archonet.com>
2009-05-19 09:53       ` Sebastien FLAESCH <sf@4js.com>
2009-05-20 06:42         ` Scott Bailey <artacus@comcast.net>
2009-05-19 09:57       ` Richard Huxton <dev@archonet.com>
2009-05-31 21:35 ` Tom Lane <tgl@sss.pgh.pa.us>

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox