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
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 |