Thread: timetz range check issue

When inserting a timetz in binary mode, there are no range checks on the time 
value (nor on the zone).  In text mode, things are fine:

postgres=# insert into t values ('24:00:00.000001-05'::timetz);
ERROR:  date/time field value out of range: "24:00:00.000001-05"

// 24:00:00.000001-05
double d = ((24 * MINS_PER_HOUR + 0) * SECS_PER_MINUTE) + 0 + 0.000001);

postgres=# select * from t;        val
--------------------
 24:00:00.000001-05

It displays it correctly, but it doesn't seem like proper behavior.  If I insert 
25:00:00.000000-05, I get nothing:

postgres=# select * from t; val
-----

(1 row)

QUERY-LOG:
LOG:  execute <unnamed>: INSERT INTO timetz_test VALUES ($1)
DETAIL:  parameters: $1 = 'p£  '

I get no error from libpq.  I think a range check is needed in timetz_recv & 
time_recv.

version: (interger_datetimes=off)
PostgreSQL 8.3devel on x86_64-unknown-linux-gnu, compiled by GCC gcc (GCC) 4.1.1 
20070105 (Red Hat 4.1.1-52)

Andrew

Andrew Chernow <ac@esilo.com> writes:
> I think a range check is needed in timetz_recv & time_recv.

I think that the design philosophy for the binary I/O code is to be as
fast as safely possible, and accordingly range-checks are present only
where needed for the backend to defend itself.  Is there anything that
goes horribly wrong if a client shoves a bad zone offset at us?

(If we want to change this philosophy, I won't necessarily quibble,
but I don't think these two recv routines are the only ones that
would need to be tightened up.)
        regards, tom lane

 >Tom Lane wrote:>>range-checks are present only where needed for the backend to defend itself

Survival is very important, but so is maintaining data integrity.  IMHO, data 
validation should be as consistent as possible.  If the backend refuses data on 
one hand but allows it on the other, confusion sets in.  I realize that binary 
input can't always be 100% validated, but a best effort is good form.  It looks 
like most recv funcs already have checks, where a check is somewhat meaningful.

andrew