Andrew Chernow <ac@esilo.com> writes: > This proposal extends libpq by adding a printf style functions for > sending and recveiving through the paramterized interface. I think a printf-style API is fundamentally a bad idea in this context. printf only works well when the set of concepts (datatypes, format specifiers, etc) is small and fixed; neither of which adjectives describe PG's set of datatypes. You've already had to go to two-character format codes in order to have even slightly mnemonic codes for the most commonly used built-in types; that doesn't look like it's going to scale up for long. And what are you going to do about add-on data types, such as contrib stuff, PostGIS and other add-on projects, or user-defined types? > PQputf offers a way of packing pgtypes for use with the parameterized > functions. One or more values can be put at the same time. The params > are stored within the PGconn struct as a PGparam structure (internal > API only). The paramspec describes the pgtypes that you want to put. > In the paramspec, anything other than a valid conversion specifiers is > ignored. "%n4, -@#= %n8" is treated the same way as "%n4%n8". > Once all params have been put, one of four paramterized functions that > are aware of PGparam can be used: I find the idea of embedding state like that into the PGconn to be pretty horrid, as well. It makes the design non-reentrant --- consider the example of wanting to execute a query during the process of computing parameters for a later query. If there's merit in the idea at all, expose PGparam as a separate (but opaque) data structure that is explicitly passed into and out of the functions that are concerned with it. > * PQexecParams > * PQexecPrepared > * PQsendQueryParams > * PQsendQueryPrepared You can't just randomly change the behavior of existing API functions. > Date and time types: > dt time, timetz > dd date > dT timestamp, timestamptz > di interval I'm not sure whether timestamp/timestamptz can or should be treated as interchangeable; but time and timetz definitely are not. BTW, how will this code react to the inevitable future changes in binary formats? As examples, show what you'd do with * the 8.2-to-8.3 change in the width of type money * the likely future change to type timestamptz to store original timezone explicitly * the likely future change to type text to store encoding/collation info explicitly If the answer is that libpq will be unable to deal with these events, I think the proposal is dead in the water. There's a reason why we aren't pushing client-side use of binary formats very hard: in many cases those formats are subject to change. There might be some value in the concept of building up parameter values in a PGparam object before passing it to an eventual PQexec-like function. However, I see no reason to tie that concept to the use of binary parameter format. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match

Andrew Chernow <ac@esilo.com> writes: > For starters, if binary results is a feature you wish you could uninvent > then we are probably dead in the water for that reason. This goes to > the core of our concept. Not really: AFAICS you could implement exactly the API you have sketched without any reliance on binary data transmission whatsoever. As long as PGparam is an opaque struct, library users would have no idea whether the values they provide are being sent as text or binary. You should probably take two steps back and think about what aspects of what you want to do are really involved with providing an easier-to-use API for PQexecParams and friends, and what parts are actually interested in binary data transmission (and why). Separating those issues in your mind might produce more clarity. > In the end, some of these changes would change the text format right? I'd consider that fairly unlikely. For instance, the money width change didn't impact the text format (except to the extent that longer values are now legal), and remembering a timestamptz's zone wouldn't impact the text representation either. Another example is that any significant re-implementation of type NUMERIC (say, as a bignum integer plus exponent instead of the current BCD-ish format) would probably change its binary representation, but there'd be no need for a text change. The bottom line to me is that binary representations are inherently a lot more fragile and version-dependent than text representations. Our attitude so far has been that client-side code that wants to use binary data transmission is taking all the risk of changes on itself. ("If it breaks, you get to keep both pieces.") It's not clear to me what we gain by making libpq subject to those risks. If we could have libpq insulate client apps from these kinds of changes, that would be one thing; but AFAICS, with these more complex types, a binary format change would usually also dictate a change in what the library exposes to clients. As far as I saw, your proposal completely glossed over the issue of exactly what data structure would be exposed to clients for anything more complex than an integer. I'm afraid that that structure would be subject to change, and then we'd just have two layers of brokenness on our hands instead of only one. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend