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
On Dec 22, 2007 7:40 PM, Andrew Chernow <ac@esilo.com> wrote:
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.
+1
--
Usama Munir Dar http://www.linkedin.com/in/usamadar
Consultant Architect
Cell:+92 321 5020666
Skype: usamadar