Re: [HACKERS] [PATCH] Generic type subscripting

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Dmitry Dolgov <9erthalion6(at)gmail(dot)com>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Alexander Korotkov <aekorotkov(at)gmail(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, David Steele <david(at)pgmasters(dot)net>, Nikita Glukhov <n(dot)gluhov(at)postgrespro(dot)ru>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, David Fetter <david(at)fetter(dot)org>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Oleksandr Shulgin <oleksandr(dot)shulgin(at)zalando(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Oleg Bartunov <obartunov(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] [PATCH] Generic type subscripting
Date: 2020-12-26 18:24:04
Message-ID: 1292981.1609007044@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dmitry Dolgov <9erthalion6(at)gmail(dot)com> writes:
>> On Tue, Dec 22, 2020 at 02:21:22PM -0500, Tom Lane wrote:
>> 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'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?

Right, with the important proviso that the coercion strength is
COERCION_IMPLICIT not COERCION_ASSIGNMENT.

> 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?

No, there's no such IMPLICIT-level casts. Coercing bigint down to int
is only allowed at ASSIGNMENT or higher coercion strength.

In a case like jsonpath['...'], the initially UNKNOWN-type literal could
in theory be coerced to any of these types, so you'd have to resolve that
case manually. The overloaded-function code has an internal preference
that makes it choose TEXT if it has a choice of TEXT or some other target
type for an UNKNOWN input (cf parse_func.c starting about line 1150), but
if you ask can_coerce_type() it's going to say TRUE for all three cases.

Roughly speaking, then, I think what you want to do is

1. If input type is UNKNOWNOID, choose result type TEXT.

2. Otherwise, apply can_coerce_type() to see if the input type can be
coerced to int4, text, or jsonpath. If it succeeds for none or more
than one of these, throw error. Otherwise choose the single successful
type.

3. Apply coerce_type() to coerce to the chosen result type.

4. At runtime, examine exprType() of the input to figure out what to do.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-12-26 18:37:15 Re: Better client reporting for "immediate stop" shutdowns
Previous Message Tom Lane 2020-12-26 18:07:41 Re: pglz compression performance, take two