diff options
author | Peter Eisentraut <peter_e@gmx.net> | 2009-09-09 19:00:09 +0000 |
---|---|---|
committer | Peter Eisentraut <peter_e@gmx.net> | 2009-09-09 19:00:09 +0000 |
commit | 3ab8b7fa6f9ac2fb04096f8860261dc42d59a570 (patch) | |
tree | d9598757858432e236e77e7c43538a87099f6fbf /src/backend | |
parent | 255f66efa9b648500a4f06b839d0256987406f0f (diff) | |
download | postgresql-3ab8b7fa6f9ac2fb04096f8860261dc42d59a570.tar.gz postgresql-3ab8b7fa6f9ac2fb04096f8860261dc42d59a570.zip |
Fix/improve bytea and boolean support in PL/Python
Before, PL/Python converted data between SQL and Python by going
through a C string representation. This broke for bytea in two ways:
- On input (function parameters), you would get a Python string that
contains bytea's particular external representation with backslashes
etc., instead of a sequence of bytes, which is what you would expect
in a Python environment. This problem is exacerbated by the new
bytea output format.
- On output (function return value), null bytes in the Python string
would cause truncation before the data gets stored into a bytea
datum.
This is now fixed by converting directly between the PostgreSQL datum
and the Python representation.
The required generalized infrastructure also allows for other
improvements in passing:
- When returning a boolean value, the SQL datum is now true if and
only if Python considers the value that was passed out of the
PL/Python function to be true. Previously, this determination was
left to the boolean data type input function. So, now returning
'foo' results in true, because Python considers it true, rather than
false because PostgreSQL considers it false.
- On input, we can convert the integer and float types directly to
their Python equivalents without having to go through an
intermediate string representation.
original patch by Caleb Welton, with updates by myself
Diffstat (limited to 'src/backend')
-rw-r--r-- | src/backend/utils/adt/domains.c | 39 |
1 files changed, 38 insertions, 1 deletions
diff --git a/src/backend/utils/adt/domains.c b/src/backend/utils/adt/domains.c index 0aaa9b8be16..5b58ee81a09 100644 --- a/src/backend/utils/adt/domains.c +++ b/src/backend/utils/adt/domains.c @@ -25,7 +25,7 @@ * * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/utils/adt/domains.c,v 1.8 2009/01/01 17:23:49 momjian Exp $ + * $PostgreSQL: pgsql/src/backend/utils/adt/domains.c,v 1.9 2009/09/09 19:00:09 petere Exp $ * *------------------------------------------------------------------------- */ @@ -302,3 +302,40 @@ domain_recv(PG_FUNCTION_ARGS) else PG_RETURN_DATUM(value); } + +/* + * domain_check - check that a datum satisfies the constraints of a + * domain. extra and mcxt can be passed if they are available from, + * say, a FmgrInfo structure, or they can be NULL, in which case the + * setup is repeated for each call. + */ +void +domain_check(Datum value, bool isnull, Oid domainType, void **extra, MemoryContext mcxt) +{ + DomainIOData *my_extra = NULL; + + if (mcxt == NULL) + mcxt = CurrentMemoryContext; + + /* + * We arrange to look up the needed info just once per series of calls, + * assuming the domain type doesn't change underneath us. + */ + if (extra) + my_extra = (DomainIOData *) *extra; + if (my_extra == NULL) + { + my_extra = (DomainIOData *) MemoryContextAlloc(mcxt, + sizeof(DomainIOData)); + domain_state_setup(my_extra, domainType, true, mcxt); + if (extra) + *extra = (void *) my_extra; + } + else if (my_extra->domain_type != domainType) + domain_state_setup(my_extra, domainType, true, mcxt); + + /* + * Do the necessary checks to ensure it's a valid domain value. + */ + domain_check_input(value, isnull, my_extra); +} |