Re: [HACKERS] Re: issue: record or row variable cannot be part of multiple-item INTO list
On Tue, Sep 19, 2017 at 11:29 AM, Tom Lane 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.
Re: [HACKERS] Re: issue: record or row variable cannot be part of multiple-item INTO list
"David G. Johnston" writes: > On Tue, Sep 19, 2017 at 2:12 PM, Tom Lane wrote: >> Notice the parens/comma positioning. It's only because text is such >> a lax datatype that you didn't notice the problem. > I saw exactly what you described - that it didn't error out and that the > text representation of the single output composite was being stored in the > first field of the target composite. i.e., that it "worked". Does that > fact that it only works if the first field of the composite type is text > change your opinion that the behavior is OK to break? No. That's not "working" for any useful value of "working". I would indeed be happy if we could just change this behavior, but I do not care to answer to the crowd of villagers that will appear if we do that. It's just way too easy to do, eg, declare r record; ... for r in select lots-o-columns from ... loop ... and then expect r to contain all the columns of the SELECT, separately. We can't change that behavior now. (And making FOR behave differently for this purpose than INTO wouldn't be very nice, either.) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: issue: record or row variable cannot be part of multiple-item INTO list
On Tue, Sep 19, 2017 at 2:12 PM, Tom Lane wrote:
> "David G. Johnston" writes:
> > Actually, this does work, just not the way one would immediately expect.
>
> On closer inspection, what's actually happening in your example is that
> you're getting the SELECT's ct1 result crammed into the first column of
> c1, and then a default NULL is stuck into its second column:
>
> > ct1: (text, text)
>
> > DO $$
> > SELECT ('1', '2')::ct1 INTO c1;
> > RAISE NOTICE '%', c1;
> > END;
> > $$;
>
> > Notice: ("(1,2)",)
>
> Notice the parens/comma positioning. It's only because text is such
> a lax datatype that you didn't notice the problem.
>
>
I saw exactly what you described - that it didn't error out and that the
text representation of the single output composite was being stored in the
first field of the target composite. i.e., that it "worked". Does that
fact that it only works if the first field of the composite type is text
change your opinion that the behavior is OK to break?
David J.
Re: [HACKERS] Re: issue: record or row variable cannot be part of multiple-item INTO list
"David G. Johnston" writes:
> Actually, this does work, just not the way one would immediately expect.
On closer inspection, what's actually happening in your example is that
you're getting the SELECT's ct1 result crammed into the first column of
c1, and then a default NULL is stuck into its second column:
> ct1: (text, text)
> DO $$
> SELECT ('1', '2')::ct1 INTO c1;
> RAISE NOTICE '%', c1;
> END;
> $$;
> Notice: ("(1,2)",)
Notice the parens/comma positioning. It's only because text is such
a lax datatype that you didn't notice the problem.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: issue: record or row variable cannot be part of multiple-item INTO list
"David G. Johnston" writes: >> Aside from being inconsistent, it doesn't cover all >> the cases --- what if you have just one query output column, that is >> composite, and you'd like it to go into a composite variable? 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. > Actually, this does work, just not the way one would immediately expect. Uh ... how did you declare ct1, exactly? I tried this before claiming it doesn't work, and it doesn't, for me: create type complex as (r float8, i float8); create or replace function mkc(a float8, b float8) returns complex language sql as 'select a,b'; select mkc(1,2); create or replace function test() returns void language plpgsql as $$ declare c complex; begin select mkc(1,2) into c; raise notice 'c = %', c; end$$; select test(); I get ERROR: invalid input syntax for type double precision: "(1,2)" CONTEXT: PL/pgSQL function test() line 4 at SQL statement That's because it's trying to assign the result of mkc() into c.r, not into the whole composite variable. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: issue: record or row variable cannot be part of multiple-item INTO list
On Tue, Sep 19, 2017 at 11:29 AM, Tom Lane wrote:
> Aside from being inconsistent, it doesn't cover all
> the cases --- what if you have just one query output column, that is
> composite, and you'd like it to go into a composite variable? 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.
>
Actually, this does work, just not the way one would immediately expect.
ct1: (text, text)
DO $$
SELECT ('1', '2')::ct1 INTO c1;
RAISE NOTICE '%', c1;
END;
$$;
Notice: ("(1,2)",)
And so, yes, my thinking has a backward compatibility problem. But one
that isn't fixable when constrained by backward compatibility - whether
this patch goes in or not.
David J.
Re: [HACKERS] Re: issue: record or row variable cannot be part of multiple-item INTO list
2017-09-19 20:29 GMT+02:00 Tom Lane : > Pavel Stehule writes: > > 2017-09-14 12:33 GMT+02:00 Anthony Bykov : > >> As far as I understand, this patch adds functionality (correct me if I'm > >> wrong) for users. Shouldn't there be any changes in doc/src/sgml/ with > the > >> description of new functionality? > > > It removes undocumented limit. I recheck plpgsql documentation and there > > are not any rows about prohibited combinations of data types. > > I remain of the opinion that this patch is a fundamentally bad idea. > It creates an inconsistency between what happens if the INTO target list > is a single record/row variable (it absorbs all the columns of the query > output) and what happens if a record/row variable is part of a > multi-variable target list (now it just absorbs one column, which had > better be composite). That's going to confuse people, especially since > you haven't documented it. But even with documentation, it doesn't seem > like good design. Aside from being inconsistent, it doesn't cover all > the cases --- what if you have just one query output column, that is > composite, and you'd like it to go into a composite variable? 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. I'm wondering about "var.*" or "(var)" as > the notation signaling that you want the former, though neither of > those seem like they're very intuitive. > > If we had a notation like that, it'd be possible to ask for either > behavior within a larger target list, except that we'd still need > to say that I-want-a-RECORD-variable-to-absorb-N-scalar-columns > has to be the only thing in its target list. Otherwise it's not > very clear what N ought to be. (In some cases maybe you could > reverse-engineer N from context, but I think that'd be overly > complicated and bug prone.) > I am not sure if I understand to your objection. This patch do nothing with RECORD variables - where is is impossible or pretty hard to implement any clean solution. If we do some sophisticated game with multiple RECORD type variables, then probably some positional notations has sense, and in this case we cannot to allow mix scalar and composite values. so SELECT s,s, C,s,C TO sv, sv, CV, s, RV should be allowed but so SELECT s,s, C,s,C TO R, CV, s, RV should be disallowed Regards Pavel > > regards, tom lane >
Re: [HACKERS] Re: issue: record or row variable cannot be part of multiple-item INTO list
Pavel Stehule writes: > 2017-09-14 12:33 GMT+02:00 Anthony Bykov : >> As far as I understand, this patch adds functionality (correct me if I'm >> wrong) for users. Shouldn't there be any changes in doc/src/sgml/ with the >> description of new functionality? > It removes undocumented limit. I recheck plpgsql documentation and there > are not any rows about prohibited combinations of data types. I remain of the opinion that this patch is a fundamentally bad idea. It creates an inconsistency between what happens if the INTO target list is a single record/row variable (it absorbs all the columns of the query output) and what happens if a record/row variable is part of a multi-variable target list (now it just absorbs one column, which had better be composite). That's going to confuse people, especially since you haven't documented it. But even with documentation, it doesn't seem like good design. Aside from being inconsistent, it doesn't cover all the cases --- what if you have just one query output column, that is composite, and you'd like it to go into a composite variable? 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. I'm wondering about "var.*" or "(var)" as the notation signaling that you want the former, though neither of those seem like they're very intuitive. If we had a notation like that, it'd be possible to ask for either behavior within a larger target list, except that we'd still need to say that I-want-a-RECORD-variable-to-absorb-N-scalar-columns has to be the only thing in its target list. Otherwise it's not very clear what N ought to be. (In some cases maybe you could reverse-engineer N from context, but I think that'd be overly complicated and bug prone.) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: issue: record or row variable cannot be part of multiple-item INTO list
2017-09-19 11:43 GMT+02:00 Anthony Bykov : > The following review has been posted through the commitfest application: > make installcheck-world: tested, passed > Implements feature: tested, passed > Spec compliant: tested, passed > Documentation:tested, passed > > Hello, > I've tested it (make check-world) and as far as I understand, it works > fine. > > The new status of this patch is: Ready for Committer > Thank you very much Pavel > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers >
[HACKERS] Re: issue: record or row variable cannot be part of multiple-item INTO list
The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: tested, passed Documentation:tested, passed Hello, I've tested it (make check-world) and as far as I understand, it works fine. The new status of this patch is: Ready for Committer -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: issue: record or row variable cannot be part of multiple-item INTO list
Hi 2017-09-14 12:33 GMT+02:00 Anthony Bykov : > The following review has been posted through the commitfest application: > make installcheck-world: tested, passed > Implements feature: tested, passed > Spec compliant: not tested > Documentation:tested, failed > > Hello, > As far as I understand, this patch adds functionality (correct me if I'm > wrong) for users. Shouldn't there be any changes in doc/src/sgml/ with the > description of new functionality? > It removes undocumented limit. I recheck plpgsql documentation and there are not any rows about prohibited combinations of data types. There is line: where command-string is an expression yielding a string (of type text) containing the command to be executed. The optional target is a record variable, a row variable, or a comma-separated list of simple variables and record/row fields, into which the results of the command will be stored. The optional USING expressions supply values to be inserted into the command. what is correct if I understand well with this patch. Regards Pavel > > Regards > Anthony > > The new status of this patch is: Waiting on Author > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers >
[HACKERS] Re: issue: record or row variable cannot be part of multiple-item INTO list
The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: not tested Documentation:tested, failed Hello, As far as I understand, this patch adds functionality (correct me if I'm wrong) for users. Shouldn't there be any changes in doc/src/sgml/ with the description of new functionality? Regards Anthony The new status of this patch is: Waiting on Author -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: issue: record or row variable cannot be part of multiple-item INTO list
Hi
I am sending rebased patch
Regards
Pavel
diff --git a/src/pl/plpgsql/src/pl_gram.y b/src/pl/plpgsql/src/pl_gram.y
index 94f1f58593..4b6bf0b5bc 100644
--- a/src/pl/plpgsql/src/pl_gram.y
+++ b/src/pl/plpgsql/src/pl_gram.y
@@ -92,9 +92,10 @@ static char *NameOfDatum(PLwdatum *wdatum);
static void check_assignable(PLpgSQL_datum *datum, int location);
static void read_into_target(PLpgSQL_rec **rec, PLpgSQL_row **row,
bool *strict);
-static PLpgSQL_row *read_into_scalar_list(char *initial_name,
- PLpgSQL_datum *initial_datum,
- int initial_location);
+static void read_into_list(char *initial_name,
+ PLpgSQL_datum *initial_datum, int initial_location,
+ PLpgSQL_datum **scalar,
+ PLpgSQL_rec **rec, PLpgSQL_row **row);
static PLpgSQL_row *make_scalar_list1(char *initial_name,
PLpgSQL_datum *initial_datum,
int lineno, int location);
@@ -1558,33 +1559,9 @@ for_variable : T_DATUM
{
$$.name = NameOfDatum(&($1));
$$.lineno = plpgsql_location_to_lineno(@1);
- if ($1.datum->dtype == PLPGSQL_DTYPE_ROW)
- {
- $$.scalar = NULL;
- $$.rec = NULL;
- $$.row = (PLpgSQL_row *) $1.datum;
- }
- else if ($1.datum->dtype == PLPGSQL_DTYPE_REC)
- {
- $$.scalar = NULL;
- $$.rec = (PLpgSQL_rec *) $1.datum;
- $$.row = NULL;
- }
- else
- {
- int tok;
- $$.scalar = $1.datum;
- $$.rec = NULL;
- $$.row = NULL;
- /* check for comma-separated list */
- tok = yylex();
- plpgsql_push_back_token(tok);
- if (tok == ',')
-$$.row = read_into_scalar_list($$.name,
- $$.scalar,
- @1);
- }
+ read_into_list($$.name, $1.datum, @1,
+ &$$.scalar, &$$.rec, &$$.row);
}
| T_WORD
{
@@ -3337,89 +3314,21 @@ check_assignable(PLpgSQL_datum *datum, int location)
}
/*
- * Read the argument of an INTO clause. On entry, we have just read the
- * INTO keyword.
- */
-static void
-read_into_target(PLpgSQL_rec **rec, PLpgSQL_row **row, bool *strict)
-{
- int tok;
-
- /* Set default results */
- *rec = NULL;
- *row = NULL;
- if (strict)
- *strict = false;
-
- tok = yylex();
- if (strict && tok == K_STRICT)
- {
- *strict = true;
- tok = yylex();
- }
-
- /*
- * Currently, a row or record variable can be the single INTO target,
- * but not a member of a multi-target list. So we throw error if there
- * is a comma after it, because that probably means the user tried to
- * write a multi-target list. If this ever gets generalized, we should
- * probably refactor read_into_scalar_list so it handles all cases.
- */
- switch (tok)
- {
- case T_DATUM:
- if (yylval.wdatum.datum->dtype == PLPGSQL_DTYPE_ROW)
- {
-check_assignable(yylval.wdatum.datum, yylloc);
-*row = (PLpgSQL_row *) yylval.wdatum.datum;
-
-if ((tok = yylex()) == ',')
- ereport(ERROR,
- (errcode(ERRCODE_SYNTAX_ERROR),
- errmsg("record or row variable cannot be part of multiple-item INTO list"),
- parser_errposition(yylloc)));
-plpgsql_push_back_token(tok);
- }
- else if (yylval.wdatum.datum->dtype == PLPGSQL_DTYPE_REC)
- {
-check_assignable(yylval.wdatum.datum, yylloc);
-*rec = (PLpgSQL_rec *) yylval.wdatum.datum;
-
-if ((tok = yylex()) == ',')
- ereport(ERROR,
- (errcode(ERRCODE_SYNTAX_ERROR),
- errmsg("record or row variable cannot be part of multiple-item INTO list"),
- parser_errposition(yylloc)));
-plpgsql_push_back_token(tok);
- }
- else
- {
-*row = read_into_scalar_list(NameOfDatum(&(yylval.wdatum)),
- yylval.wdatum.datum, yylloc);
- }
- break;
-
- default:
- /* just to give a better message than "syntax error" */
- current_token_is_not_variable(tok);
- }
-}
-
-/*
* Given the first datum and name in the INTO list, continue to read
- * comma-separated scalar variables until we run out. Then construct
+ * comma-separated variables until we run out. Then construct
* and return a fake "row" variable that represents the list of
- * scalars.
+ * fields. When there is only one rec or row field, then return
+ * this variable without nesting.
*/
-static PLpgSQL_row *
-read_into_scalar_list(char *initial_name,
- PLpgSQL_datum *initial_datum,
- int initial_location)
+static void
+read_into_list(char *initial_name,
+ PLpgSQL_datum *initial_datum, int initial_location,
+ PLpgSQL_datum **scalar, PLpgSQL_rec **rec, PLpgSQL_row **row)
{
int nfields;
char *fieldnames[1024];
int varnos[1024];
- PLpgSQL_row *row;
+ PLpgSQL_row *auxrow;
int tok;
check_assignable(initial_datum, initial_location);
@@ -3427,6 +3336,21 @@ read_into_scalar_list(char *initial_name,
varnos[0] = initial_datum->dno;
nfields = 1;
+ *rec = NULL;
+ *row = NULL;
+ if (scalar)
+ *scalar = NULL;
+
+ /*
+ * save row or rec if list has
Re: [HACKERS] Re: issue: record or row variable cannot be part of multiple-item INTO list
2017-09-07 19:48 GMT+02:00 Pavel Stehule : > > > 2017-09-07 8:08 GMT+02:00 Anthony Bykov : > >> The following review has been posted through the commitfest application: >> make installcheck-world: not tested >> Implements feature: not tested >> Spec compliant: not tested >> Documentation:not tested >> >> I'm afraid this patch conflicts with current master branch. >> >> The new status of this patch is: Waiting on Author >> > > rebased > I am sorry - wrong patch I am sending correct patch Regards Pavel > > > >> >> -- >> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) >> To make changes to your subscription: >> http://www.postgresql.org/mailpref/pgsql-hackers >> > > plpgsql-into-multitarget-2.sql Description: application/sql -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: issue: record or row variable cannot be part of multiple-item INTO list
2017-09-07 8:08 GMT+02:00 Anthony Bykov :
> The following review has been posted through the commitfest application:
> make installcheck-world: not tested
> Implements feature: not tested
> Spec compliant: not tested
> Documentation:not tested
>
> I'm afraid this patch conflicts with current master branch.
>
> The new status of this patch is: Waiting on Author
>
rebased
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
diff --git a/src/pl/plpgsql/src/pl_comp.c b/src/pl/plpgsql/src/pl_comp.c
index a637551..49327b2 100644
--- a/src/pl/plpgsql/src/pl_comp.c
+++ b/src/pl/plpgsql/src/pl_comp.c
@@ -409,6 +409,7 @@ do_compile(FunctionCallInfo fcinfo,
for (i = 0; i < numargs; i++)
{
char buf[32];
+char *argname = NULL;
Oid argtypeid = argtypes[i];
char argmode = argmodes ? argmodes[i] : PROARGMODE_IN;
PLpgSQL_type *argdtype;
@@ -433,9 +434,12 @@ do_compile(FunctionCallInfo fcinfo,
errmsg("PL/pgSQL functions cannot accept type %s",
format_type_be(argtypeid;
+argname = (argnames && argnames[i][0] != 0) ? argnames[i] : NULL;
+
/* Build variable and add to datum list */
-argvariable = plpgsql_build_variable(buf, 0,
- argdtype, false);
+argvariable = plpgsql_build_variable(argname != NULL ?
+ argname : buf,
+ 0, argdtype, false);
if (argvariable->dtype == PLPGSQL_DTYPE_VAR)
{
@@ -461,9 +465,9 @@ do_compile(FunctionCallInfo fcinfo,
add_parameter_name(argitemtype, argvariable->dno, buf);
/* If there's a name for the argument, make an alias */
-if (argnames && argnames[i][0] != '\0')
+if (argname != '\0')
add_parameter_name(argitemtype, argvariable->dno,
- argnames[i]);
+ argname);
}
/*
diff --git a/src/test/regress/expected/plpgsql.out b/src/test/regress/expected/plpgsql.out
index 7ebbde6..a9fe736 100644
--- a/src/test/regress/expected/plpgsql.out
+++ b/src/test/regress/expected/plpgsql.out
@@ -5979,3 +5979,15 @@ LINE 1: SELECT (SELECT string_agg(id || '=' || name, ',') FROM d)
^
QUERY: SELECT (SELECT string_agg(id || '=' || name, ',') FROM d)
CONTEXT: PL/pgSQL function alter_table_under_transition_tables_upd_func() line 3 at RAISE
+-- should fail -- message should to contain argument name
+CREATE TYPE ct AS (a int, b int);
+CREATE OR REPLACE FUNCTION fx(x ct)
+RETURNS void AS $$
+BEGIN
+ GET DIAGNOSTICS x = ROW_COUNT;
+end;
+$$ language plpgsql;
+ERROR: "x" is not a scalar variable
+LINE 4: GET DIAGNOSTICS x = ROW_COUNT;
+ ^
+DROP TYPE ct;
diff --git a/src/test/regress/sql/plpgsql.sql b/src/test/regress/sql/plpgsql.sql
index 60d1d38..4716ac0 100644
--- a/src/test/regress/sql/plpgsql.sql
+++ b/src/test/regress/sql/plpgsql.sql
@@ -4766,3 +4766,15 @@ ALTER TABLE alter_table_under_transition_tables
DROP column name;
UPDATE alter_table_under_transition_tables
SET id = id;
+
+-- should fail -- message should to contain argument name
+CREATE TYPE ct AS (a int, b int);
+
+CREATE OR REPLACE FUNCTION fx(x ct)
+RETURNS void AS $$
+BEGIN
+ GET DIAGNOSTICS x = ROW_COUNT;
+end;
+$$ language plpgsql;
+
+DROP TYPE ct;
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Re: issue: record or row variable cannot be part of multiple-item INTO list
The following review has been posted through the commitfest application: make installcheck-world: not tested Implements feature: not tested Spec compliant: not tested Documentation:not tested I'm afraid this patch conflicts with current master branch. The new status of this patch is: Waiting on Author -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
