Re: BUG #3002: PQexecParams only supports some commands; needs improved error reporting, documenting or fixing
От | Tom Lane |
---|---|
Тема | Re: BUG #3002: PQexecParams only supports some commands; needs improved error reporting, documenting or fixing |
Дата | |
Msg-id | 19059.1171438759@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | BUG #3002: PQexecParams only supports some commands; needs improved error reporting, documenting or fixing ("Phil Endecott" <spam_from_postgresql_bugs@chezphil.org>) |
Ответы |
Re: BUG #3002: PQexecParams only supports some commands;
needs improved error reporting, documenting or fixing
|
Список | pgsql-bugs |
"Phil Endecott" <spam_from_postgresql_bugs@chezphil.org> writes: > I understand that PQexecParams may only be used for SELECT, INSERT, DELETE > and UPDATE commands, but not for other commands where parameter substitution > might be useful such as CREATE VIEW and CREATE TABLE AS SELECT. When I used > PQexecParams with CREATE VIEW with one $ parameter I got no error > immediately, but got a "no value found for parameter 1" error when I later > ran a query that used the view. As near as I can tell, your issue is that you haven't thought carefully about what "$1" in a CREATE VIEW *means*. Is it supposed to represent a constant value bound into the view when it's created? Is it supposed to represent a value supplied whenever the view is used (if so, how do you disambiguate when the query calling the view uses $1 for its own purposes?). Or something else? Given defensible arguments for a particular answer to these definitional questions, we might think about implementing something, but right now my instinct is to not go there. I'm not seeing a use-case that would justify work on this. regards, tom lane
В списке pgsql-bugs по дате отправления: