2010/12/10 Merlin Moncure <mmonc...@gmail.com> > On Fri, Dec 10, 2010 at 12:40 PM, Dmitriy Igrishin <dmit...@gmail.com> > 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.
