Re: VARIANT / ANYTYPE datatype - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: VARIANT / ANYTYPE datatype
Date
Msg-id BANLkTinjZ73Z5FCtKEwx3uw8sO41HUj-rA@mail.gmail.com
Whole thread Raw
In response to Re: VARIANT / ANYTYPE datatype  (Joseph Adams <joeyadams3.14159@gmail.com>)
List pgsql-hackers
2011/5/11 Joseph Adams <joeyadams3.14159@gmail.com>:
> On Tue, May 10, 2011 at 10:29 PM, Joseph Adams
> <joeyadams3.14159@gmail.com> wrote:
>> The VARIANT type, or similar, would be useful for the JSON data type
>> I've been intermittently working on, as it would allow us to create a
>> function like this:
>>
>>    from_json(JSON) returns VARIANT
>
> This occurred to me: if PostgreSQL functions could return ANYELEMENT,
> then we could just say:
>
>    from_json(JSON) returns ANYELEMENT -- no intermediate VARIANT value
>
> Likewise, the variant conversion functions (which could be invoked
> automatically) could be done this way:
>
>    to_variant(ANYELEMENT) returns VARIANT
>    from_variant(VARIANT) returns ANYELEMENT
>
> However, I'm not familiar enough with the innards of PostgreSQL's type
> system to know if returning ANYELEMENT would be possible and make
> sense.
>

it isn't possible. You can have a ANYELEMENT on input and output, or
ANYELEMENT on input, but you ca't have ANYELEMENT just on output. The
analogy for ANYELEMENT is C++ template.

Regards

Pavel Stehule

VARIANT is maybe good idea - it can simplify a PL/pgSQL code - but
though anybody about using this type in planner?


> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>


pgsql-hackers by date:

Previous
From: Joseph Adams
Date:
Subject: Re: VARIANT / ANYTYPE datatype
Next
From: Bruce Momjian
Date:
Subject: Re: the big picture for index-only scans