<[EMAIL PROTECTED]> writes: >> I don't necessarily object to PQexecf() as a shortcut for some >> multi-step operation, but I don't think you've got the format string >> semantics down yet.
> I'm thinking that we could start with the "standard" conversion > specifiers - those are well understood and would be expected by just > about any C developer. > In particular, the %d, %u, %e, and %f format specifiers are immediately > useful. > If we start with the "standard" set, you can start to use PQexecf() > immediately and we could promise to maintain *at least* that set. That's exactly the approach I don't want to take. To implement our quoting-escape additions, we'll have to stop relying on sprintf and implement for ourselves whatever "standard C" escapes we want to support. Then we'd have a backwards compatibility problem anywhere that the local sprintf() implements escapes that go beyond the standard. That means we'd be buying into *at least* as much complexity as is in src/port/snprintf.c, probably rather more, plus ongoing portability headaches while we find out what people happen to have depended on. And that's before we've added any value at all. I think it's simply not sane to start off with an sprintf-based implementation when we fully intend to have custom code later. We need a small, tightly specified set of escapes so that we aren't forced to support a pile of stuff that has little if any use for SQL-query construction. As an example, I see the use for %d but not the use for %-012.6d, to say nothing of $-reordering. But shipping a stopgap version of PQexecf would lock us into supporting all of that cruft. 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