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