[Libpqxx-general] pqxx::pipeline as a means of "posting" a call to a pl/pgSQL function

[Jeroen Vermeulen]

Peter Geoghegan wrote:

> Very useful, thank you. I'm happy enough to use pipeline in this way,
> but the case could be made that having a convenience method that is
> similar to "result pqxx::transaction_base::exec(  const
> PGSTD::stringstream & Query, const PGSTD::string & Desc =
> PGSTD::string())" that would be called, say, "post", that returns void
> and never stalls(as its name suggests, "posting" a query), would be of
> general utility. I'm not sure how easily implemented such a method
> would be, as pqxx's innards are well encapsulated from me, but it's
> something to consider.

That does sound interesting.  However the devil is in the details: a lot 
of code might have to be extended to check for ongoing "post" 
statements, and complete any that may be pending.  Even if there's no 
return value you're interested in, errors still need to be detected and 
raised as exceptions (typically during some libpqxx call after the 
post() one).  That becomes a problem if the function that detects the 
error can't throw exceptions.  Don't know off the top of my head whether 
that actually occurs anywhere though.

The pipeline makes it all explicit: you state that you want to operate 
in this special environment, and that you are ready to deal with its 
quirks.  The library can simply forbid you to do certain things while 
you have a pipeline open, which is a state you can recognize statically 
in your code.  Otherwise I might have to say "you can't do this while 
you have any post() statements pending," which is harder to keep track of.

Of course I have been known to over-think these things.  The pipeline is 
an API experiment; maybe if we go over the code in detail and consider 
all the interactions we find that (part of) its functionality fits 
naturally into the transaction class.  But it'd take a lot of time for a 
relatively small gain.


> Incidentally, my offer to create a demo application showcasing pqxx
> with MFC ( Microsoft's wrapper classes for the win32 API) stands. Is
> the demo database created by the demo/test programs SQL-ascii encoded?

It may be worth talking to Kirit Saelensminde about that, by the way! 
Kirit is working on a way to generate Visual C++ project files, in such 
a way that they pick up your own settings as needed to make the library 
compatible with other programs.  I imagine there would be some useful 
interaction between the two ideas.

The tests don't create the test database, though they do set up the 
actual tables and data.  Any roughly ASCII-compatible choice of locale 
should work on the backend, as far as the existing test suite is concerned.


> I don't recall. I guess if it was, I'd use multibyte/ "Ansi" encoding
> for the application - this is a variable byte-per-character (one or
> two bytes) ascii superset that supports extended Latin characters, the
> euro symbol etc. There are no invalid byte-sequences with this
> encoding, so Postgres will never complain, no matter what you store
> (you won't be storing Chinese or Arabic though). Perhaps a demo
> application isn't appropriate at all (because it will so trivial), I'm
> not sure - as I've said before though, mySQL++ has an MFC demo
> application when I last looked about a year ago, so this is well
> precedented.

If you are going to set up a database as part of the application, might 
as well make it a full Unicode one.  The client application doesn't have 
to run in the same encoding as the database, and postgres supports full 
bidirectional conversion in UTF-8-encoded backends.  (Except for 
characters that the target encoding doesn't have, of course).


Jeroen