Re: PATCH: Implement value_to_json for single-datum conversion

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Craig Ringer <ringerc(at)ringerc(dot)id(dot)au>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PATCH: Implement value_to_json for single-datum conversion
Date: 2012-08-13 05:55:04
Message-ID: 23141.1344837304@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Craig Ringer <ringerc(at)ringerc(dot)id(dot)au> writes:
> As for the value_to_json crashing, works for me:

> postgres=# SELECT value_to_json(42);
> value_to_json
> ---------------
> 42
> (1 row)

Oh, right, because there actually is support for anyelement in the
underlying C function. There is not in the quote_literal case.

> Purely so I understand what the correct handling of the anyelement+text
> overload would've been: In light of your comments on opr_sanity would
> the right approach be to add a second C function like text_to_json that
> only accepts 'text' to avoid confusing the sanity check?

Actually, given the above, what did you need value_to_json(text) for at
all? Wouldn't value_to_json(anyelement) have covered it?

But yeah, the general approach to suppressing complaints from that
opr_sanity test is to make more C entry points. The point of it,
in some sense, is that if you want to make an assumption that two
types are binary-equivalent then it's better to have that assumption
in C code than embedded in the pg_proc entries. The cases that we
let pass via the "expected" outputs are only ones where binary
equivalence seems pretty well assured, like text vs varchar.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Craig Ringer 2012-08-13 06:16:50 Re: PATCH: Implement value_to_json for single-datum conversion
Previous Message Craig Ringer 2012-08-13 05:33:01 Re: PATCH: Implement value_to_json for single-datum conversion