Re: [HACKERS] issue: record or row variable cannot be part of multiple-item INTO list - Mailing list pgsql-hackers

> On 20 Sep 2017, at 01:05, David G. Johnston <david.g.johnston@gmail.com> wrote:
>
> On Tue, Sep 19, 2017 at 11:29 AM, Tom Lane <tgl@sss.pgh.pa.us <mailto:tgl@sss.pgh.pa.us>> wrote:
> ​T​hat​ ​doesn't work today, and this patch doesn't fix it, but it does create
> enough confusion that we never would be able to fix it.
>
> I'd be much happier if there were some notational difference
> between I-want-the-composite-variable-to-absorb-a-composite-column
> and I-want-the-composite-variable-to-absorb-N-scalar-columns.
> For backwards compatibility with what happens now, the latter would
> have to be the default.
>
> ​So, using "()" syntax​
>
> s,t: scalar text
> c,d: (text, text)
>
> treat all numbers below as text; and the ((1,2),) as ("(1,2)",)
>
> A. SELECT 1 INTO s; -- today 1, this patch is the same
>
> B. SELECT 1, 2 INTO s; -- today 1, this patch is the same
>
> C. SELECT 1, 2 INTO (s); -- ERROR syntax - scalars cannot be tagged with (), this patch N/A
>
> D. SELECT 1, 2 INTO s, t; -- today 1, 2, this patch is the same
>
> E. SELECT 1, 2 INTO c; -- today (1,2), this patch is the same
>
> F. SELECT 1, 2 INTO (c); --ERROR "1" cannot be converted to (text, text), this patch N/A
>
> 1. SELECT (1,2) INTO c; -- today ((1,2),); this patch is the same
>
> 2. SELECT (1,2) INTO (c); -- (1,2) -- this patch N/A
>
> 3. SELECT (1,2),(3,4) INTO c,d; -- ERROR syntax -- this patch gives [I think...it can be made to give] (1,2),(3,4)
>
> 4. SELECT (1,2),(3,4) INTO c,(d); -- ERROR syntax -- this patch N/A
>
> 5. SELECT (1,2),(3,4) INTO (c),d; -- ERROR syntax -- this patch N/A
>
> 6. SELECT (1,2),(3,4) INTO (c),(d); -- (1,2),(3,4) -- this patch N/A
>
> !. SELECT 1, (2,3), 4 INTO s, (c), t -- 1, (2,3), 4 -- this patch N/A
> @. SELECT 1, 2, 3, 4 INTO s, (c), t -- ERROR "2" cannot be made into (text, text) -- this patch N/A
>
> IOW, this patch, if "c" is the only target (#1) and is composite pretend the user wrote "INTO c.1, c.2" and assign
eachoutput column as a scalar in one-by-one fashion.  If "c" is not the only target column (#3) assign a single output
columnto it.  This maintains compatibility and clean syntax at the cost of inconsistency. 
>
> The alternate, backward compatible, option introduces mandatory () in the syntax for all composite columns in a
multi-variabletarget (# 3-5 errors, #6 valid) while it changes the behavior if present on a single variable target (#1
vs#2). 
>
> So, allowing #3 to work makes implementing #2 even more unappealing.  Making only #2 and #6 work seems like a
reasonablealternative position. 
>
> The last option is to fix #1 to return (1,2) - cleanly reporting an error if possible, must like we just did with
SRFs,and apply the patch thus gaining both consistency and a clean syntax at the expense of limited backward
incompatibility.
>
> Arrays not considered; single-column composites might end up looking like scalars when presented to a (c) target.
>
> Hope this helps someone besides me understand the problem space.

Based on the discussion in this thread I’ve moved this patch to the next CF
with the new status Waiting for author, as it seems to need a revised version.

cheers ./daniel



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