On 26/05/2009, at 10:25 AM, Tom Lane wrote:
Andrew McNamara 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
those functions when tryi
Andrew McNamara 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)
To make changes to your sub
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 m
Stephen Frost 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
>> back-patch becaus
* 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 considerat
Andrew McNamara 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()
checks neither the time nor t
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 p
