On Tue, Apr 8, 2008 at 3:22 PM, Tom Lane <[EMAIL PROTECTED]> wrote: > Andrew Chernow <[EMAIL PROTECTED]> writes: > > Tom Lane wrote: > >> Better support for arrays and composites is certainly something that > >> people might want, but the problem with this design is that it forces > >> them to buy into a number of other decisions that they don't necessarily > >> want.
> > What decisions are we forcing upon the libpq user? > > Well, for starters, using binary format. It is undeniable that that > creates more portability risks (cross-architecture and cross-PG-version > issues) than text format. Not everyone wants to take those risks for > benefits that may not be meaningful for their apps. personally, I think these claims of portability are a bit overblown...they are trivially checked by regressions tests. the version question is more interesting and solutions range from the easy (force version match to access binary types) to the complex. > The other forced decision is the whole PQputf/PQgetf notation, which > people may or may not find natural --- it still seems a pretty poor > choice to me for this specific problem. PQputf, in the form where > you're generating a SQL command string along with some parameters, > isn't too unreasonable, but unless you've already bought into binary > parameter handling it's not gaining all that much either. And > PQgetf is just weird. The format of a PGresult is generally well > known by the app; trying to force it into the model of string > scanning is a poor fit. For instance there's no mapping at all > for what to do with constant parts of the format string. We chose to do the PQgetf function that way as a compromise of many different requirements (we went through several alternative implementations before settling on the final one). At minimum, you have to supply at least _some_ type information because getf writes into application memory, and aside from the obvious safety issues, there are user defined types to consider. Since you can register additional type into the handler system at runtime (including 'automagic' discovery of composite types by name), there has to be some way of directing the library to the proper handler. Since everything is driven by typename, it all comes down to how you want to do this. We like the varargs style since it provides some symmetry with putf and feels 'right' in coding. The only other approach to getf that meets all the requirements would be like this: PQgetf(result, tup_num, "date", 0, &date); // not varargs where the typestring is fixed to one type...you could only pull out one parameter at a time (no variable argument list). We considered this carefully, and we opted for the submitted approach as the best solution. One other benefit to doing things this way is we get to alter the 'format escape character, (%)', to # when lookup by name as opposed to column position is desired. The constant part of the format string in getf are ignored, they have no meaning in that context. Same with putf. Although, there is PQputvf which will take something like this: "select %int4 + %int4" and turn it into "select $1 + $2". In PQputvf, everything surrounding the type modifier is still ignored. So, the API is symmetrical in terms of type string, except that for query execution there is an extra stage where the query string is mapped. What you find to be weird here I think is rather elegant :-). >>PQputf/PQgetf notation, which > people may or may not find natural --- it still seems a pretty poor > choice to me for this specific problem We reference types by there name (can include schema as well). There is no better mnemonic than that ... is there? For example, if I have some funky type 'foo' defined on the server, what is more natural than pulling that type with %foo (which can be optionally schema qualified)? By the way, we ended up with the current implementation based on your concerns with previous attempts (using two letter format codes, or exported static type handlers)...(we really like how things turned out though...using schema qualified type names as the 'typespec' really makes the libpq code look 'pretty'. merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers