Andrew McNamara andr...@object-craft.com.au writes:
When submitting a query via the V3 binary protocol (PQexecParams,
paramFormats[n]=1), it appears the PostgreSQL server performs no range
checking on the passed values.
A quick look at time_recv() shows this is true, and timetz_recv()
* Tom Lane (t...@sss.pgh.pa.us) wrote:
I'm not entirely sure why we put a range limit on time values at all,
but given that we do, it'd probably be a good idea to check the range
in the recv functions. I'm inclined to fix this for 8.4, but not
back-patch because of compatibility
Stephen Frost sfr...@snowman.net writes:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
I'm not entirely sure why we put a range limit on time values at all,
but given that we do, it'd probably be a good idea to check the range
in the recv functions. I'm inclined to fix this for 8.4, but not
On 26/05/2009, at 5:41 AM, Tom Lane wrote:
The only place I can find where an oversize time value behaves in a
seriously bogus fashion is in time_out, or more specifically
EncodeTimeOnly(): it fails to initialize its output string at all.
So you could easily get garbage text output, though in
Andrew McNamara andr...@object-craft.com.au writes:
Are there any other cases where the binary receive functions are
missing sanity checks?
Possibly --- you want to go looking?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
On 26/05/2009, at 10:25 AM, Tom Lane wrote:
Andrew McNamara andr...@object-craft.com.au writes:
Are there any other cases where the binary receive functions are
missing sanity checks?
Possibly --- you want to go looking?
Uh. I'd be lying if I said I wanted to - I got enough of a taste of
When submitting a query via the V3 binary protocol (PQexecParams,
paramFormats[n]=1), it appears the PostgreSQL server performs no range
checking on the passed values. Passing values greater than 24 hours
results in unpredictable results (dumps that cannot be restored,
strange output when
