> Right, this would be the shortcoming. Unfortunately there is no Python
> class representing a json, and the mapping object -> adapter is by
> python class only. I assume your create_employee function cannot take
> *any* json: it may be expecting e.g. a dict and not a list, and maybe
> some specific attributes while ignoring others. For this case it's
> probably easy to create a Python object that knows how to adapt to
> json syntax. But in the generic case a Json can be a python string, or
> a list, or a dict, or None, each of which have a more reasonable
> Postgres representation.
I have no better suggestion for the general case and I agree that for
the general case the thin wrapper totally makes sense.
The only idea: maybe have a "convenience option" that when turned on
makes Python dicts adapt to PG JSON automatically.
If there is no other "default mapping" of Python dicts to any other
PG type, that would make a nice fallback that probably allows to handle
a lot of situations automatically - such as stored procs that expect
their JSON args to be dicts anyway.
>
> If anybody comes with a better solution than the Json wrapper I'd be
> happy to know.
No, not for the general case.
>
> BTW, because of the zope problem discussed today, I'd be happy to have
> a release soon, so if nobody steps ahead in the next few hours, I'll
> try and implement the json support tonight and have it for psycopg
> 2.4.6.
Ok. Great! (Not that I want to "freeride" .. but I guess it's a snap for
you and me would need to first "learn" Psycopg tests/docs ..
Thanks!
Tobias
>
> -- Daniele
>