From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: bug in json_to_record with arrays |
Date: | 2014-11-26 22:48:43 |
Message-ID: | 2672.1417042123@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
>> As far as your request for a better error message is concerned, I'm a
>> bit inclined to lay the blame on array_in rather than the JSON code.
>> Wouldn't it be better if it said
>>
>> ERROR: invalid input syntax for array: "["potter","chef","programmer"]"
>> DETAIL: Dimension value is missing.
> Sounds pretty reasonable to me, but I would just caution that we should
> check if that's considered 'leakproof' or not (or, if it is, if it'd
> ever possibly leak data it shouldn't or if it would only ever return
> information provided by the user).
array_in could only be regarded as leakproof if every element-type input
function it could ever call is also leakproof. Which ain't the case,
so I sure hope it's not marked that way. (Likewise record_in, range_in,
etc.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2014-11-26 23:00:50 | Re: Maximum number of WAL files in the pg_xlog directory |
Previous Message | Andrew Dunstan | 2014-11-26 22:41:55 | Re: memory explosion on planning complex query |