>> 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

                        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

Reply via email to