Re: [HACKERS] Re: issue: record or row variable cannot be part ofmultiple-item INTO list

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: [HACKERS] Re: issue: record or row variable cannot be part ofmultiple-item INTO list
Дата
Msg-id CAKFQuwZonPiYABcQCSiGgOfKzL62cDpnUZOHaXyv+b-azDy_YA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Re: issue: record or row variable cannot be part of multiple-item INTO list  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] issue: record or row variable cannot be part of multiple-item INTO list  (Daniel Gustafsson <daniel@yesql.se>)
Список pgsql-hackers
Дерево обсуждения
On Tue, Sep 19, 2017 at 11:29 AM, Tom Lane <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 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.

David J.

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] Rewriting the test of pg_upgrade as a TAP test
Следующее
От: Melanie Plageman
Дата:
Сообщение: Re: [HACKERS] [PATCH v1] Add and report the new "in_hot_standby" GUC pseudo-variable.