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

flexi adaption/casting scheme

From: Tobias Oberstein <tobias(dot)oberstein(at)gmail(dot)com>
To: psycopg(at)postgresql(dot)org
Subject: flexi adaption/casting scheme
Date: 2012-09-20 21:50:46
Message-ID: (view raw, whole thread or download thread mbox)
Lists: psycopg

I'd like to implement a certain type adaption/casting scheme
and struggle with the right approach. Maybe someone can give
me a hint? Would be great and welcome!

Context: I am _only_ concerned with calling stored procedures,
so there is the complete type metadata from PG catalog regarding
the PG side available to use for mapping.

PG => Py (typecasting):

hstore => plain Python dict

JSON => json.loads() .. whatever Python object that gives

composite type => plain Python dict with key/value pairs only
for all attributes in the composite type that have non-NULL values

everything else => as per-default with Psycopg

Py => PG (adaption):

plain Python dict ..:

PG target type = hstore => dict-to-hstore with conversion of keys/values 
to str repr. if needed

PG target type = JSON => json.dumps() whatever str that produces

PG target type = composite type => for every key in the Python dict that 
is an attribute in the composite type, fill in the value from the dict; 
for every attribute in the composite type where there is no key in the 
Python dict, fill in NULL

everything else => as per-default with Psycopg


Above should work with nested PG types (array of composite type with
an attribute again composite type etc etc).

It should work with IN, OUT, INOUT parameters and array, setof, etc 
returning procedures.


How do I tackle this? Or even more fundamental: is it sane / doable at 
all (using public Psycopg hooks only)?

Thanks alot,


psycopg by date

Next:From: Daniele VarrazzoDate: 2012-09-21 00:08:25
Subject: Dealing with a change in Python 3.3 memoryview
Previous:From: Federico Di GregorioDate: 2012-09-20 07:48:04
Subject: Re: Range Type Support

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