Are there some "direct casts" for JSONB parameters? - postgresql

Question

This is a typical wrap function (overloading a non-json foo() function) for use in JSONB context,
-- suppose FUNCTION foo(text[], numeric, boolean) returns int.
CREATE FUNCTION foo(JSONB) RETURNS int AS $f$
SELECT foo(
(SELECT array_agg(x) FROM jsonb_array_elements_text($1->'list') t(x) ),
($1->>'lim')::numeric, -- why cast JSONB number to numeric?
($1->>'osort')::boolean -- idem for boolean
);
$f$ LANGUAGE SQL IMMUTABLE;
Is there an elegant way to cast a JSONB string array into SQL text array? Why we need this ugly numeric and boolean casts if the internal representation says its datatypes?
EDITED after good #IgorRomanchenko discussion:
PHILOSOPHIC NOTES
My preocupation is
Why PostreSQL 9.5 is losing JSONB internal datatype information and internal (number and boolean) representations?
In nowadays the runtime engine use CPU to convert JSONB number to text and text to SQL numeric, or boolean to text them text to boolean... Ideal (optimized) is "to by-pass" JSONB internal representations, or only casts "binary to binary" (not parse to text and cast text to binary).
PostgreSQL will be more optimized and friendly when internally using JSONB datatype (jsonb_typeof)!
PS1: the SELECT array_agg(x) FROM jsonb_array_elements_text() example only amplifies and exposes the same problem. In this case we also need a direct jsonb_array_to_array(x,type) function to by-pass array bynary representation.
PS2: CREATE CAST is not a solution to this problem, because destroys the original JSONB representations.
... How to do it?
Hum... Perhaps creating alternative casting types like ::numericByPass to "bypass JSONB binary number to SQL numeric" and ::booleanByPass "bypass JSONB boolean to SQL boolean", so, preserving internal representation, not parsing it as a text value. Of course, if runtime check see string instead expected datatype, it triggers an error.
Looking at the example we see that the context obligates to use number and boolean, the user not need to say it to the compiler.
The SQL parser can use this implicit "context obligation" to do by it self, in compile time, the cast to ::numericByPass and ::booleanByPass, preserving JSONB internal representations. If the user is really afraid about string inputs, only in this case the user will add explicit ::numeric and ::boolean castings.

Answer 1

You need runtime casts and checks because an input JSON does not define any structure. You can not check that this input JSON has field "list" with text array in it or a field "lim" with an integer.
Take this example JSON:
{
"list":42,
"lim": [3,5],
"osort": "maybe"
}
Current function will throw type cast exceptions because it has runtime casts and checks. What will this function do without any runtime checks?
BTW If you really want postgres to do this for you - you can enable implicit cast from varchar to int and boolean as in this post: Postgresql. CREATE CAST 'character varying' to 'integer'
It is not the best idea, but it will work.

Answer 2

You can create different operators similar to ->> that produce different output types. For example, -># could give you a number and ->| a boolean.
CREATE FUNCTION json_numeric(
j json
, e text
) RETURNS NUMERIC IMMUTABLE STRICT LANGUAGE SQL AS $$
SELECT (j->>e)::numeric
$$;
CREATE OPERATOR -># ( PROCEDURE = json_numeric, LEFTARG = json, RIGHTARG = text );
SELECT ('{"a": 42, "b": "1"}')::json -># 'a';
?column?
----------
42
(1 row)
SELECT ('{"a": 42, "b": "1"}')::json -># 'b';
?column?
----------
1
(1 row)
If you used plpgsql you could throw an error if json_typeof() wasn't correct, but note that will be significantly slower than the SQL version (though in most usage that won't matter).