> On 20 Sep 2017, at 01:05, David G. Johnston <david.g.johns...@gmail.com> > wrote: > > On Tue, Sep 19, 2017 at 11:29 AM, Tom Lane <t...@sss.pgh.pa.us > <mailto:t...@sss.pgh.pa.us>> wrote: > That 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 each output column as a scalar in > one-by-one fashion. If "c" is not the only target column (#3) assign a > single output column to 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-variable target (# 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 reasonable alternative 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
