Re: [HACKERS] Last minute mini-proposal (I know, Iknow)forPQexecf()
Added to TODO: o Add PQexecf() that allows complex parameter substitution http://archives.postgresql.org/pgsql-hackers/2007-03/msg01803.php --- [EMAIL PROTECTED] wrote: 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. Ok - then it seems like it might make sense to implement PQexecf() in terms of src/port/snprintf.c (and enhance that family of functions to support the quoting conversion specifiers that we want). Let's just pick up this discussion in the next release cycle. Bruce - can you add a TODO for this topic? Thanks. -- Korry -- Korry Douglas[EMAIL PROTECTED] EnterpriseDB http://www.enterprisedb.com -- 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 6: explain analyze is your friend
Re: [HACKERS] Last minute mini-proposal (I know, Iknow)forPQexecf()
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. We can add more specifiers (for proper quoting and such) later - we can't break existing client applications if we just add to the set of supported specifiers; the function gets more useful as time goes by. -- Korry
Re: [HACKERS] Last minute mini-proposal (I know, Iknow)forPQexecf()
[EMAIL PROTECTED] 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 ---(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, Iknow)forPQexecf()
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. Ok - then it seems like it might make sense to implement PQexecf() in terms of src/port/snprintf.c (and enhance that family of functions to support the quoting conversion specifiers that we want). Let's just pick up this discussion in the next release cycle. Bruce - can you add a TODO for this topic? Thanks. -- Korry -- Korry Douglas[EMAIL PROTECTED] EnterpriseDB http://www.enterprisedb.com
Re: [HACKERS] Last minute mini-proposal (I know, Iknow)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: I tried to forget the singing... it was your evil laughter that still haunts my dreams. -- Korry
