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

BUG #5272: PL/Python SELECT: return composite fields as dict, not str

From: "Steve White" <swhite(at)aip(dot)de>
To: pgsql-bugs(at)postgresql(dot)org
Subject: BUG #5272: PL/Python SELECT: return composite fields as dict, not str
Date: 2010-01-11 16:41:07
Message-ID: 201001111641.o0BGf7cw063967@wwwmaster.postgresql.org (view raw or flat)
Thread:
Lists: pgsql-bugs
The following bug has been logged online:

Bug reference:      5272
Logged by:          Steve White
Email address:      swhite(at)aip(dot)de
PostgreSQL version: 8.4.2
Operating system:   Linux
Description:        PL/Python SELECT: return composite fields as dict, not
str
Details: 

Hi, 

As recently posted in the mailing list,
http://archives.postgresql.org/pgsql-general/2010-01/msg00389.php
(where you will find a test file, not reproduced here.):

The plpy.execute() command on a SELECT returns a list of nice dictionaries
keyed on field names, containing the fields.  For numeric types, the type of
the dictionary values are as expected.  Unfortunately however, if a field
contains a composite type, it is flattened to a string.

I would have expected a composite type field to be returned as a dictionary
of values of the proper types, keyed on the names of the elements of the
composite type.  After all, it's a DB system that supports hierarchies, and
a programming language that beautifully supports them.

In my case, I was able to work around this problem in an ugly way, but I can
imagine cases where this would render PL/Python unsuitable.

I see nothing in the documentation about this
	http://www.postgresql.org/docs/8.4/static/plpython.html
It only talks about passing composite types into and out of functions.

This is an unpleasant discovery for those working to a deadline.  Perhaps a
"limitations" section for the doc would be in order.  (You could also list
the limitations of PL/Python regarding returning RECORD types.)

But the best thing to do would be to fix it.

For backward compatibility, you might implement a switch that turns on the
hierarchical interpretation of fields, and leave the current behaviour as
the default.

Cheers!

Responses

pgsql-bugs by date

Next:From: Alex HunsakerDate: 2010-01-11 18:10:53
Subject: Re: plperl & sort
Previous:From: Robert HaasDate: 2010-01-11 14:38:34
Subject: Re: BUG #5271: pg_dump: schema with OID 22519 does not exist

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