Search Postgresql Archives

Re: Extended query protocol and exact types matches.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





2010/12/10 Merlin Moncure <mmoncure@xxxxxxxxx>
On Fri, Dec 10, 2010 at 12:40 PM, Dmitriy Igrishin <dmitigr@xxxxxxxxx> wrote:
> Hey Merlin,
>
> Thank you for explanation !
>
> Yes, I understand that specifying NULL instead real OID will provoke
> the parser attempts to infer the data types in the same way as it would
> do for untyped literal string constants.
> But there are three string types: text, varchar(n) and character(n) which
> has a different OIDs but they are all in the same type category. So, is it
> worth it to implement some Varchar and Character types (which actually
> wraps Text) at the library level or specifying the OID of text for contexts
> where these parameters actually varchar or char (i.e. types of same
> category) are safe?

not really, at the end of the day, you are coming in from C char*, so
just send TEXTOID and let the server worry about what to do if say you
are passing into varchar or (more rarely char(n)). Âlibpqtypes, the
library you are pretending doesn't exist,
Me ? :-) !true ! I just pretend not to bloat libpq and keep it clean...
does this
(http://libpqtypes.esilo.com/man3/pqt-specs.html). ÂPGtext is
typedef'd char* and the only format string for character types is
%text.

IMNSHO, If you wanted to attack this problem in an actually novel and
useful way in C++ style, I would consider taking the libpqtypes
library, rip out all the format string stuff, and rig variadic
templates so you could leverage variadic queries. ÂMaybe this could be
integrated into libpqxx, not sure.Â

printf : cout :: : PQexecf Â: query

query(conn, "select $1 + $2", 3, 7);

'query' is hypothetical function that uses template type inference,
mapping/marshaling data and building the data structure that
PQexecParams points to (in libpqtypes, the PGparam). ÂParsing the type
format string is expensive enough that we had to implement a client
side prepare to reduce the cost of searching type handlers over and
over. ÂOf course, cout is not really faster than printf, but that's
another topic :-).
I've implemented client side prepare too! :-) So, I am on right way and
not alone! :-)

merlin

Thank you very much ! You help me a lot!

--
// Dmitriy.



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux