json, jsonb, and casts

In 9.3 we changed the way json generating functions worked by taking
account of cast functions to json from non-builtin types, such as hstore.

In 9.5 I am proposing to provide similar functionality for jsonb. The
patch actually takes account of cast functions to both jsonb and json
(with jsonb preferred). If there is a cast to jsonb, we use it and then
merge the result into the jsonb being accumulated. If there is just a
cast to json, we use it, and then parse that directly into the result
datum.

It was arguably a bit of an oversight not to take account of casts to
jsonb in 9.4 in datum_to_json(). So I'm thinking of rolling into this
patch changes to json.c::datum_to_json() and friends to take analogous
account of casts to jsonb (i.e. call the cast function, turn the
resulting jsonb into a cstring and append it to the result).

Thoughts?

cheers

andrew

Andrew Dunstan <andrew(dot)dunstan(at)pgexperts(dot)com> writes:
> In 9.3 we changed the way json generating functions worked by taking
> account of cast functions to json from non-builtin types, such as hstore.

> In 9.5 I am proposing to provide similar functionality for jsonb. The
> patch actually takes account of cast functions to both jsonb and json
> (with jsonb preferred). If there is a cast to jsonb, we use it and then
> merge the result into the jsonb being accumulated. If there is just a
> cast to json, we use it, and then parse that directly into the result
> datum.

> It was arguably a bit of an oversight not to take account of casts to
> jsonb in 9.4 in datum_to_json(). So I'm thinking of rolling into this
> patch changes to json.c::datum_to_json() and friends to take analogous
> account of casts to jsonb (i.e. call the cast function, turn the
> resulting jsonb into a cstring and append it to the result).

Meh. This leaves it very ambiguous which cast function would be applied
if both are available. I think it's overcomplicated anyway.

regards, tom lane

On 11/06/2014 03:58 PM, Tom Lane wrote:
> Andrew Dunstan <andrew(dot)dunstan(at)pgexperts(dot)com> writes:
>> In 9.3 we changed the way json generating functions worked by taking
>> account of cast functions to json from non-builtin types, such as hstore.
>> In 9.5 I am proposing to provide similar functionality for jsonb. The
>> patch actually takes account of cast functions to both jsonb and json
>> (with jsonb preferred). If there is a cast to jsonb, we use it and then
>> merge the result into the jsonb being accumulated. If there is just a
>> cast to json, we use it, and then parse that directly into the result
>> datum.
>> It was arguably a bit of an oversight not to take account of casts to
>> jsonb in 9.4 in datum_to_json(). So I'm thinking of rolling into this
>> patch changes to json.c::datum_to_json() and friends to take analogous
>> account of casts to jsonb (i.e. call the cast function, turn the
>> resulting jsonb into a cstring and append it to the result).
> Meh. This leaves it very ambiguous which cast function would be applied
> if both are available. I think it's overcomplicated anyway.
>
>

OK, then we can do one of these:

* just honor casts to json, whether generating json or jsonb, or
* just honor casts to json when generating json (as now) and just
casts to jsonb when generating jsonb, ignoring the other casts in
both cases.

I can see a case for each, so I won't be too fussed either way. On
balance I probably favor the first option, as it means you would only
need to supply one cast function to have the type behave as you want,
and functions providing casts to json are going to be a LOT easier to write.

cheers

andrew