On 11/26/2014 03:48 PM, Tom Lane wrote:
> Arguably,
> populate_record_worker should be smart enough to convert somehow, but
> it isn't today. Looks to me like it wouldn't succeed for the comparable
> case of converting a sub-object to a Postgres composite type, either.
> I'm satisfied with regarding those cases as missing features to be
> added later.
Right. Before commit a749a23d7af4dba9b3468076ec561d2cbf69af09 it didn't
try by default to treat the value as text, but instead errored out if
the value was an array or object, with an appropriate message. Now we
always try to treat it as text and pass that to the array or composite
input functions, who now get the responsibility of telling us what's wrong.
It might be possible to process such values recursively, but it would be
far from trivial.
>
> 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.
>
> which is comparable to what you'd get out of most other input functions
> that were feeling indigestion?
>
>
+1
cheers
andrew