From: | Andrew Chernow <ac(at)esilo(dot)com> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [PATCHES] libpq type system 0.9a |
Date: | 2008-04-09 00:47:38 |
Message-ID: | 47FC122A.7040000@esilo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
>
> I think a wise thing would be for the patch submitters to give a _basic_
> outline of what PQparam is trying to accomplish --- I mean like 10-20
> lines with a code snippet, or code snippet with/withouth PQparam.
>I found this posting from August, 2007 but
> it isn't short/clear enough:
>
That is very old. There are tons of examples if you download the patch
and look at some of the documentation .txt files.
>
> FYI, it might be interesting to extend it to cover what ecpg wants ---
> we have been looking for a way to get the database-dependent parts of
> ecpg out of the ecpg directory and this might be a solution, _even_ if
> it makes your library larger.
>
I am not all to familiar with ecpg. Our idea is nothing more than data
type converters, there are no type operators.
Our goal is to leverage the binary parameterized API and offer the
ability to get C types from an enhanced PQgetvalue, PQgetf. PQgetf
understands the external binary format of the backend, so it can convert
that to C types. It also understand how to convert text output from the
backend. This allows existing applications using text results to drop
in PQgetf here and there. You don't have to use PGparam or PQputf at
all to use PQgetf.
PQputf, allows one to pack parameters into a PQparam object that can be
executed at another time. It knows how to take C types and convert them
to the backend's external binary format. The patch always sends data in
binary format, but can get results in text or binary.
Along the way, we devised a way for user-defined types to be used. This
introduced PQregisterTypeHandler. This function can allow one to
sub-class existing type handlers, like extending "%timestamp" and making
"%epoch". It allows registering user-defined types. the type will be
looked up in the backend and resolved properly. It also allows one to
create aliases .. simple domains. Let's say you have a C type, typedef
int user_id;. You could register an alias where "user_id=int4". Now
you can putf and getf "%user_id". this abstracts code from possible
integer width changes, you just change your typedef and registration
code to "user_id=int8".
Take a peak at the documentation files in the patch, root of tar *.txt
files. they are very verbose and have loads of examples. The
regression-test.c file has lots of use cases.
latest:
http://www.esilo.com/projects/postgresql/libpq/typesys-0.9b.tar.gz
To sum it up, the main concepts are PQputf, PQgetf and
PQregisterTypeHandler. The other functions maintain a PGparam or
exec/send one.
--
Andrew Chernow
eSilo, LLC
http://www.esilo.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-04-09 00:53:01 | Re: pgsql: Remove mention of the Berkeley origins of the alias "Postgres" |
Previous Message | Bruce Momjian | 2008-04-09 00:44:07 | pgsql: Remove mention of the Berkeley origins of the alias "Postgres" |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2008-04-09 01:07:44 | Re: Concurrent psql patch |
Previous Message | Andrew Chernow | 2008-04-09 00:31:05 | Re: [PATCHES] libpq type system 0.9a |