On Thu, April 5, 2007 04:41, John Mudd wrote: > Here's my entire test program. I'm using 8.2.3 postgres and 2.6.9 > libpqxx. I'm trying to break up the loading of a prepared statement > into individual steps so I can write generic code to dynamically > populate any prepared statement. I show two attempts below. Each > fails with a different exception. Any suggestions? I'll try looking > at the libpqxx code...
I can't figure this one out... It's almost like an invocation of operator() is being mistaken for a constructor call. If you want to look at the libpqxx, code, most of what you'll want to see is in transaction_base::prepared() (which only constructs an invocation) and prepared_statement.(hxx|cxx). But I don't see anything there that could give rise to this behaviour. The statement and parameter names are always treated entirely separately so I fail to see how they can get mixed up. Then, prior to 2.6.9, there were some problems with deciding when to use what support for prepared statements. This was fairly complex, but the code is quite transparent now and I can't see any possible differences of opinion between the preparation function (connection_base::register_prepared() and connection_base::prepared_exec()) about what to do. Maybe I can produce a test case over the weekend. The automated test runs try many different combinations of libpq and backend versions. Jeroen _______________________________________________ Libpqxx-general mailing list Libpqxx-general@gborg.postgresql.org http://gborg.postgresql.org/mailman/listinfo/libpqxx-general
