Re: Last minute mini-proposal (I know, Iknow)forPQexecf()

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: korryd(at)enterprisedb(dot)com
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Last minute mini-proposal (I know, Iknow)forPQexecf()
Date: 2007-04-01 19:08:28
Message-ID: 16141.1175454508@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

<korryd(at)enterprisedb(dot)com> 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeroen T. Vermeulen 2007-04-01 19:30:14 Re: Oracle indemnifies PostgreSQL on its patents
Previous Message Tom Lane 2007-04-01 18:31:41 Re: Macros for typtype (was Re: Arrays of Complex Types)