Re: Why does to_json take "anyelement" rather than "any"? - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: Why does to_json take "anyelement" rather than "any"?
Date
Msg-id CAKFQuwb7W4TKzfPT+vBw84Z0bVYgvhuMPVgcYCSmdxp5V0yk=Q@mail.gmail.com
Whole thread Raw
In response to Re: Why does to_json take "anyelement" rather than "any"?  (Mohamed Wael Khobalatte <mkhobalatte@grubhub.com>)
Responses Re: Why does to_json take "anyelement" rather than "any"?  (Nikhil Benesch <nikhil.benesch@gmail.com>)
Re: Why does to_json take "anyelement" rather than "any"?  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
On Thu, Nov 5, 2020 at 3:43 PM Mohamed Wael Khobalatte <mkhobalatte@grubhub.com> wrote:
 You can always cast to text yourself, of course, but I am not familiar with the type hierarchy enough to tell why `to_json` can't deduce that as text whereas the other function can. 

My understanding is that "any" is defined to accept that behavior - allowing any pseudo-type and unknown.  The "anyelement" polymorphic pseudo-type is defined such that only concrete known types are allowed to match - and then the rules of polymorphism apply when performing a lookup.  My uninformed conclusion is that since to_json only defines a single parameter that changing it from "anyelement" to "any" would be reasonable and the hack describe probably "just works" (though I'd test it on a wide-range of built-in types first if I was actually going to use the hack).

You only get to use "any" for a C-language function but that is indeed the case here.

David J.

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: list_free() in index_get_partition()
Next
From: Fujii Masao
Date:
Subject: Re: REFRESH MATERIALIZED VIEW and completion tag output