Re: REVIEW: PL/Python table functions

From: Jan Urbański <wulczer(at)wulczer(dot)org>
To: Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: REVIEW: PL/Python table functions
Date: 2011-01-22 15:12:00
Message-ID: 4D3AF3C0.4090302@wulczer.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 22/01/11 11:15, Hitoshi Harada wrote:
> This is a review for https://commitfest.postgresql.org/action/patch_view?id=460

Thanks,

> One issue is typmod of record type.
>
> regression=# create or replace function func1(t text) returns record
> as $$ return {'name': t, 'value': 0} $$ language plpythonu;
> regression=# select * from func1('jan') as (name text, value bigint);
> name | value
> ------+-------
> jan | 0
> (1 row)
>
> regression=# select * from func1('jan') as (name text, value int);
> ERROR: function return row and query-specified return row do not match
> DETAIL: Returned type bigint at ordinal position 2, but query expects integer.

That's a bug, thanks for spotting it.

> It seems that typmod of PLyTypeInfo is not updated over statements
> within the session. I saw the error doesn't occur when I re-connect to
> the backend after the error.

I tracked it down to caching the I/O functions for the return type. Your
example shows that you can't just discover the output record type once,
but you have to recheck whether the returned record's structure has not
changed between calls.

I implemented it by looping over the attributes of the output record and
checking if type for which we have already cached the I/O function is
binary coercible to the type that's actually in the record. This allows
the code to skip recaching the functions in the common case when the
record stays the same, and fixes the bug you found.

Attached is a new patch for table function support and an incremental
patch with the change I did. The new patch for table functions does not
apply to HEAD, it's a refinement of the previous table-functions patch.
After the refactor patches are all applied or rejected, I'll post a
frech patch that applies cleanly to HEAD.

Thanks again,
Jan

Attachment Content-Type Size
plpython-table-functions-incremental.patch text/x-patch 5.6 KB
plpython-table-functions.patch text/x-patch 33.8 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2011-01-22 16:38:23 Re: [COMMITTERS] pgsql: Move test_fsync to /contrib.
Previous Message Robert Haas 2011-01-22 14:54:53 Re: auto-sizing wal_buffers