Re: libpq and prepared statements progress for 8.0
От | Greg Stark |
---|---|
Тема | Re: libpq and prepared statements progress for 8.0 |
Дата | |
Msg-id | 87mzzswxv7.fsf@stark.xeocode.com обсуждение исходный текст |
Ответ на | Re: libpq and prepared statements progress for 8.0 ("Merlin Moncure" <merlin.moncure@rcsonline.com>) |
Ответы |
Re: libpq and prepared statements progress for 8.0
|
Список | pgsql-hackers |
> > PREPARE st(unknown) AS INSERT INTO foobar(a) VALUES ($1); > > Using PQExecParams is completely out of the question? How are you > executing your statements...PQExec? A bit of context here. The perl DBD::Pg developers are trying to figure out how to implement prepared queries sanely. As it stands now they're basically writing off both binary prepared queries and SQL based prepared queries as basically useless. It would be a shame to have a brand new binary protocol but find it ignored by driver writers. The problem is that you want to be able to do $sth = $dbh->prepare("SELECT col_a FROM tab WHERE col_b = ?");$sth->execute(1);... And not have to jump through hoops binding parameters to types and so on. Ideally the database should treat the placeholder exactly as it would a single-quoted constant. Ie, it should treat it as "unknown" and use the context around it to determine what type reader function to use to read it. That would mean the semantics would be exactly equivalent to: SELECT col_a FROM tab WHERE col_b = '1'; Without this capability using prepared statements is simply too cumbersome for application programmers. And in any case DBD::Pg wants to maintain backwards compatibility with the existing drivers which don't require binding parameter types because they simply interpolate the parameters into the query string. -- greg
В списке pgsql-hackers по дате отправления: