BUG #5314: Error in nested composite types in plpgsql.

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

--
С уважением

Олег Серов

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.  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

--
С уважением

Олег Серов

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

--
С уважением

Олег Серов

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