BUG #5272: PL/Python SELECT: return composite fields as dict, not str
От | Steve White |
---|---|
Тема | BUG #5272: PL/Python SELECT: return composite fields as dict, not str |
Дата | |
Msg-id | 201001111641.o0BGf7cw063967@wwwmaster.postgresql.org обсуждение исходный текст |
Ответы |
Re: BUG #5272: PL/Python SELECT: return composite fields as
dict, not str
|
Список | pgsql-bugs |
The following bug has been logged online: Bug reference: 5272 Logged by: Steve White Email address: swhite@aip.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!
В списке pgsql-bugs по дате отправления: