From: Dmitry Dolgov <9erthalion6@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Pavel Stehule <pavel.stehule@gmail.com>
Cc: Andres Freund <andres@anarazel.de>
Cc: Alexander Korotkov <aekorotkov@gmail.com>
Cc: Justin Pryzby <pryzby@telsasoft.com>
Cc: David Steele <david@pgmasters.net>
Cc: Nikita Glukhov <n.gluhov@postgrespro.ru>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: David Fetter <david@fetter.org>
Cc: Thomas Munro <thomas.munro@gmail.com>
Cc: Oleksandr Shulgin <oleksandr.shulgin@zalando.de>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Michael Paquier <michael.paquier@gmail.com>
Cc: Oleg Bartunov <obartunov@gmail.com>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] [PATCH] Generic type subscripting
Date: Fri, 25 Dec 2020 22:16:03 +0100
Message-ID: <20201225211603.4z6rxyc6p6pkuxoa@localhost> (raw)
In-Reply-To: <629720.1608664882@sss.pgh.pa.us>
References: <107232.1608230957@sss.pgh.pa.us>
<20201217200033.qdyjv4iimwyglnwt@localhost>
<112397.1608236975@sss.pgh.pa.us>
<20201218195925.4qj6p2kxrvkdrmur@localhost>
<20201222102531.2clsvuqww6etx3by@localhost>
<CAFj8pRCHQW72Srp28VE1Whk4+_uR8BLczh7+KFgQxo2RBsoWHw@mail.gmail.com>
<20201222161623.o7y3fumwcf6hk7jk@localhost>
<614605.1608656233@sss.pgh.pa.us>
<CAFj8pRC2bmnTaqKm=C83G5VKH5AO6GPp_7cHzzZ0=siCbjeWTA@mail.gmail.com>
<629720.1608664882@sss.pgh.pa.us>
> On Tue, Dec 22, 2020 at 02:21:22PM -0500, Tom Lane wrote:
> Pavel Stehule <pavel.stehule@gmail.com> writes:
> > But maybe we try to design some that are designed already. Is there some
> > info about index specification in SQL/JSON?
>
> We do have precedent for this, it's the rules about resolving argument
> types for overloaded functions. But the conclusion that that precedent
> leads to is that we should check whether the subscript expression can
> be *implicitly* coerced to either integer or text, and fail if neither
> coercion or both coercions succeed. I'd be okay with that from a system
> design standpoint, but it's hard to say without trying it whether it
> will work out nicely from a usability standpoint. In a quick trial
> it seems it might be okay:
>
> regression=# create function mysub(int) returns text language sql
> regression-# as $$select 'int'$$;
> CREATE FUNCTION
> regression=# create function mysub(text) returns text language sql
> as $$select 'text'$$;
> CREATE FUNCTION
> regression=# select mysub(42);
> mysub
> -------
> int
> (1 row)
>
> regression=# select mysub('foo');
> mysub
> -------
> text
> (1 row)
>
> regression=# select mysub(42::bigint);
> ERROR: function mysub(bigint) does not exist
I'm not sure I completely follow and can't immediately find the relevant
code for overloaded functions, so I need to do a perception check.
Following this design in jsonb_subscripting_transform we try to coerce
the subscription expression to both integer and text (and maybe even to
jsonpath), and based on the result of which coercion has succeeded chose
different logic to handle it, right?
And just for me to understand. In the above example of the overloaded
function, with the integer we can coerce it only to text (since original
type of the expression is integer), and with the bigint it could be
coerced both to integer and text, that's why failure, isn't?
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: 9erthalion6@gmail.com, tgl@sss.pgh.pa.us, pavel.stehule@gmail.com, andres@anarazel.de, aekorotkov@gmail.com, pryzby@telsasoft.com, david@pgmasters.net, n.gluhov@postgrespro.ru, alvherre@2ndquadrant.com, david@fetter.org, thomas.munro@gmail.com, oleksandr.shulgin@zalando.de, robertmhaas@gmail.com, michael.paquier@gmail.com, obartunov@gmail.com, peter.eisentraut@2ndquadrant.com
Subject: Re: [HACKERS] [PATCH] Generic type subscripting
In-Reply-To: <20201225211603.4z6rxyc6p6pkuxoa@localhost>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox