Skip site navigation (1) Skip section navigation (2)

REVIEW: PL/Python table functions

From: Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: REVIEW: PL/Python table functions
Date: 2011-01-22 10:15:24
Message-ID: AANLkTimaL-rVmFQrn+7k3aCCXwwRUjwvzrV+OKZEMGUv@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
This is a review for https://commitfest.postgresql.org/action/patch_view?id=460

== Submission ==
The patch applies and compiles with success, on the top of the general
refactor patch. It is possible it cannot in HEAD now that the part of
the refactor patch applied in the core. I'll check it after the whole
of refactor gets in the core.
make installcheck passes all 18 tests.

== Usability and Feature ==
The patch works fine in general. I created some functions for my tests like:

CREATE OR REPLACE FUNCTION twitter_response(q text, OUT from_user
text, OUT message text) RETURNS SETOF record AS $$
import sys
import urllib2
import simplejson

def fetch(q):
  url = 'http://search.twitter.com/search.json?q=%s' % (q)
  response = urllib2.urlopen(url)
  return response.read()

root = simplejson.loads(fetch(q))
for result in root['results']:
  from_user = result['from_user']
  message = result['text']
  yield from_user, message
$$ LANGUAGE plpythonu STRICT;

and other versions that modify parameter types, return type and the
code body itself.

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.

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.


== Performance ==
I didn't test performance regression. My static code analysis doesn't
tell it has critical performance issue.

I mark this as "Waiting on Author" for the typmod issue.


Regards,



-- 
Hitoshi Harada

Responses

pgsql-hackers by date

Next:From: Pavel StehuleDate: 2011-01-22 10:32:02
Subject: Re: Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql
Previous:From: Vladimir KokovicDate: 2011-01-22 07:46:34
Subject: pg_test_fsync problem

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group