Обсуждение: BUG #5314: Error in nested composite types in plpgsql.

The following bug has been logged online:

Bug reference:      5314
Logged by:          Oleg
Email address:      serovov@gmail.com
PostgreSQL version: 8.3/8.4
Operating system:   any
Description:        Error in nested composite types in plpgsql.
Details:

Here is it reproduce code:
It works only, when procedure is plpgsql, with sql works fine.

ROLLBACK;
BEGIN;
CREATE TABLE bug_level_tree(
    field BIGINT
);
CREATE TABLE bug_level_two(
    field bug_level_tree
);
CREATE TABLE bug_level_one(
    id BIGINT,
    field bug_level_two
);
CREATE FUNCTION bug_procedure(in_row bug_level_one) RETURNS text AS $$
BEGIN
    -- void
    SELECT 1/0;
END;
$$ LANGUAGE plpgsql;

-- All okey
SELECT '(1,)'::bug_level_one;

-- Throws error
SELECT bug_procedure('(1,)');

-- ERROR:  cannot assign non-composite value to a row variable
CONTEXT:  PL/pgSQL function "bug_procedure" while storing call arguments
into local variables

Somebody will fix this bug or not?

On Thu, Feb 4, 2010 at 7:13 PM, Oleg <serovov@gmail.com> wrote:

>
> The following bug has been logged online:
>
> Bug reference:      5314
> Logged by:          Oleg
> Email address:      serovov@gmail.com
> PostgreSQL version: 8.3/8.4
> Operating system:   any
> Description:        Error in nested composite types in plpgsql.
> Details:
>
> Here is it reproduce code:
> It works only, when procedure is plpgsql, with sql works fine.
>
> ROLLBACK;
> BEGIN;
> CREATE TABLE bug_level_tree(
>        field BIGINT
> );
> CREATE TABLE bug_level_two(
>        field bug_level_tree
> );
> CREATE TABLE bug_level_one(
>        id BIGINT,
>        field bug_level_two
> );
> CREATE FUNCTION bug_procedure(in_row bug_level_one) RETURNS text AS $$
> BEGIN
>        -- void
>    SELECT 1/0;
> END;
> $$ LANGUAGE plpgsql;
>
> -- All okey
> SELECT '(1,)'::bug_level_one;
>
> -- Throws error
> SELECT bug_procedure('(1,)');
>
> -- ERROR:  cannot assign non-composite value to a row variable
> CONTEXT:  PL/pgSQL function "bug_procedure" while storing call arguments
> into local variables
>
> --
> Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-bugs
>



--=20
=F3 =D5=D7=C1=D6=C5=CE=C9=C5=CD

=EF=CC=C5=C7 =F3=C5=D2=CF=D7

2010/2/10 Oleg Serov <serovov@gmail.com>:
> Somebody will fix this bug or not?

I'm not sure whether this is a bug.  This is an explicit cast:

SELECT '(1,)'::bug_level_one;

But I think this is an implicit cast:

SELECT bug_procedure('(1,)');

I'm not totally sure of the details, but implicit, assignment, and
explicit casts are documented to have different semantics:

http://www.postgresql.org/docs/current/static/sql-createcast.html

...Robert

Robert Haas <robertmhaas@gmail.com> writes:
> 2010/2/10 Oleg Serov <serovov@gmail.com>:
>> Somebody will fix this bug or not?

> I'm not sure whether this is a bug.

Yeah, I think it is.  The problem is that exec_move_row is taking too
many shortcuts with nulls.  If the input record is short of fields it
is willing to pass this data to exec_assign_value:

                value = (Datum) 0;
                isnull = true;
                valtype = InvalidOid;

The invalid datatype value doesn't matter in the scalar case, but
if the target is a sub-row it fails the type_is_rowtype() sanity
check in exec_assign_value.

The cleanest fix would probably be to use the target variable's
datatype here instead of InvalidOid.  Alternatively, we could
change exec_assign_value to not apply the sanity check unless
the input is non-null.

            regards, tom lane

When it could be fixed?

On Thu, Feb 11, 2010 at 9:58 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> 2010/2/10 Oleg Serov <serovov@gmail.com>:
>>> Somebody will fix this bug or not?
>
>> I'm not sure whether this is a bug.
>
> Yeah, I think it is. =9AThe problem is that exec_move_row is taking too
> many shortcuts with nulls. =9AIf the input record is short of fields it
> is willing to pass this data to exec_assign_value:
>
> =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9Avalue =3D =
(Datum) 0;
> =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9Aisnull =3D=
 true;
> =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9Avaltype =
=3D InvalidOid;
>
> The invalid datatype value doesn't matter in the scalar case, but
> if the target is a sub-row it fails the type_is_rowtype() sanity
> check in exec_assign_value.
>
> The cleanest fix would probably be to use the target variable's
> datatype here instead of InvalidOid. =9AAlternatively, we could
> change exec_assign_value to not apply the sanity check unless
> the input is non-null.
>
> =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9Aregards, tom lane
>



--=20
=F3 =D5=D7=C1=D6=C5=CE=C9=C5=CD

=EF=CC=C5=C7 =F3=C5=D2=CF=D7

Oleg Serov <serovov@gmail.com> writes:
> When it could be fixed?

Oh, it is fixed, but I forgot to reply to this thread about it.
Sorry about that.

            regards, tom lane

Thanks!, when it will be released on 8.3.X?

On Wed, Feb 24, 2010 at 6:17 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Oleg Serov <serovov@gmail.com> writes:
> > When it could be fixed?
>
> Oh, it is fixed, but I forgot to reply to this thread about it.
> Sorry about that.
>
>                        regards, tom lane
>



--=20
=F3 =D5=D7=C1=D6=C5=CE=C9=C5=CD

=EF=CC=C5=C7 =F3=C5=D2=CF=D7

2010/2/25 Oleg Serov <serovov@gmail.com>:
> Thanks!, when it will be released on 8.3.X?

Looks like the last set of back-branch releases was wrapped 12/10/09,
the set before that on 9/4/09, and the previous set on 3/13/09 (but
there was a major release in the mix there).  So I'd guess we're
getting close to it being time for another set...

...Robert