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

From: <korryd(at)enterprisedb(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Last minute mini-proposal (I know, I know) forPQexecf()
Date: 2007-03-31 13:34:16
Message-ID: 1175348056.6784.43.camel@sakai.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> Way too late for 8.3 --- if we were going to do something like this,
> we should think first and program later. In particular, blindly
> adopting the sprintf format string definition doesn't seem very helpful.
> The sorts of escapes I'd want to have are "properly quoted SQL
> identifier", "properly quoted SQL literal", etc. A large fraction of
> what sprintf knows about is more or less irrelevant to the task of
> creating SQL commands.
>
> Also, how does this interact with parameterized or prepared commands?
> If we wanted PQexecf we'd soon want PQexecParamsf, etc. I don't think
> we really want so much duplicate logic there --- it'd be better to
> decouple the string-building functionality from the query-sending
> functionality. Probably better to consider something like
> PQformatQuery() that passes back a malloc'd string.

I agree with almost everything that you said. I really like the idea of
new format specifiers for "properly quoted stuff".

I like the idea of adding a new PQformatQuery() function. And once you
have PQformatQuery(), you can easily change the implementation of
PQexecf() without affecting any client applications. I'm not sure that
we would need a PQexecParamsf(), but I'm willing to accept that we might
(it seems more likely that we would want PQpreparef()).

But we would want those features in addition to PQexecf(), not instead
of PQexecf().

PQexecf() would be useful today, even without all of those extras - just
look at the the source code for pg_dump to see how much code we would
eliminate with a simple PQexecf().

There are two reasons I threw out this idea now.

1) I didn't think of it until a few days ago...

2) It's important to get the interface into a near-future release so
that client applications can start using it soon. We can add features
and refactor the implementation later. I assume that my prototype is
not horrible (it's based on existing code).

-- Korry

--
Korry Douglas korryd(at)enterprisedb(dot)com
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2007-03-31 15:38:30 Re: CIC and deadlocks
Previous Message Simon Riggs 2007-03-31 13:14:36 Re: CIC and deadlocks