Re: Why does to_json take "anyelement" rather than "any"?

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Mohamed Wael Khobalatte <mkhobalatte(at)grubhub(dot)com>
Cc: Nikhil Benesch <nikhil(dot)benesch(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Why does to_json take "anyelement" rather than "any"?
Date: 2020-11-06 00:38:46
Message-ID: CAKFQuwb7W4TKzfPT+vBw84Z0bVYgvhuMPVgcYCSmdxp5V0yk=Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Nov 5, 2020 at 3:43 PM Mohamed Wael Khobalatte <
mkhobalatte(at)grubhub(dot)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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2020-11-06 00:45:07 Re: REFRESH MATERIALIZED VIEW and completion tag output
Previous Message Michael Paquier 2020-11-06 00:32:35 Re: list_free() in index_get_partition()