Re: [HACKERS] Last minute mini-proposal (I know, I know)forPQexecf()
On Sat, Mar 31, 2007 at 07:16:19PM -0400, Bruce Momjian wrote: Andrew Dunstan wrote: [EMAIL PROTECTED] wrote: It's important to get the *right* interface into the first release that has it. Agreed, that's why I proposed the right interface to begin with :-) Maybe the first thing we might usefully do would be to document PQExpBuffer. And you can send in a patch for that for 8.3 :-) The big question is whether these functions are for external use. We do export them using libpq/exports.txt, but I assume it was only for psql use and not for general usage. There was discussion about this before, and the conclusion then was that they're not a part of the public interface, and only intended to be used by our own frontends. Doesn't mean we can't put it out there if we think it's a good interface for people to use though ;-) //Magnus ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Last minute mini-proposal (I know, I know) forPQexecf()
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[EMAIL PROTECTED] EnterpriseDB http://www.enterprisedb.com
Re: [HACKERS] Last minute mini-proposal (I know, I know) forPQexecf()
[EMAIL PROTECTED] writes: 2) It's important to get the interface into a near-future release so that client applications can start using it soon. It's important to get the *right* interface into the first release that has it. The day before feature freeze is way too late for blue-sky design IMHO. I note that the nominal schedule http://www.postgresql.org/developer/roadmap says that all major proposals should have been made and reviewed at least a month ago. While we're still busy resolving details for a lot of things, I don't believe there is anything currently under serious consideration that hadn't at least been talked about before the beginning of March. 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
Re: [HACKERS] Last minute mini-proposal (I know, I know)forPQexecf()
It's important to get the *right* interface into the first release that has it. Agreed, that's why I proposed the right interface to begin with :-) The day before feature freeze is way too late for blue-sky design IMHO. Ok, I can certainly bring this up again in the next release cycle. And I can include my own private implementation in any client applications until we have something similar in libpq. I note that the nominal schedule http://www.postgresql.org/developer/roadmap says that all major proposals should have been made and reviewed at least a month ago. Consider me spanked... (and quit giggling Bruce). -- Korry -- Korry Douglas[EMAIL PROTECTED] EnterpriseDB http://www.enterprisedb.com
Re: [HACKERS] Last minute mini-proposal (I know, I know)forPQexecf()
[EMAIL PROTECTED] wrote: I note that the nominal schedule http://www.postgresql.org/developer/roadmap says that all major proposals should have been made and reviewed at least a month ago. Consider me spanked... (and quit giggling Bruce). Awe, you got me. :-) FYI, I sung Dream On to Korry when he first suggested this to me: http://en.wikipedia.org/wiki/Dream_On_(Aerosmith_song) -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Last minute mini-proposal (I know, I know)forPQexecf()
[EMAIL PROTECTED] wrote: It's important to get the *right* interface into the first release that has it. Agreed, that's why I proposed the right interface to begin with :-) Maybe the first thing we might usefully do would be to document PQExpBuffer. And you can send in a patch for that for 8.3 :-) cheers andrew ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Last minute mini-proposal (I know, I know)forPQexecf()
Andrew Dunstan wrote: [EMAIL PROTECTED] wrote: It's important to get the *right* interface into the first release that has it. Agreed, that's why I proposed the right interface to begin with :-) Maybe the first thing we might usefully do would be to document PQExpBuffer. And you can send in a patch for that for 8.3 :-) The big question is whether these functions are for external use. We do export them using libpq/exports.txt, but I assume it was only for psql use and not for general usage. -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Last minute mini-proposal (I know, I know)forPQexecf()
[EMAIL PROTECTED] writes: It's important to get the *right* interface into the first release that has it. Agreed, that's why I proposed the right interface to begin with :-) 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. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
