Re: psql: Add command to use extended query protocol

Поиск
Список
Период
Сортировка
От Corey Huinker
Тема Re: psql: Add command to use extended query protocol
Дата
Msg-id CADkLM=fbX7NiEzjPoX97hw4bKu-_XbbR2e-Q-+3uzx+51_yH-w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: psql: Add command to use extended query protocol  (Pavel Stehule <pavel.stehule@gmail.com>)
Ответы Re: psql: Add command to use extended query protocol
Список pgsql-hackers


what about introduction new syntax for psql variables that should be passed as bind variables.

I thought about basically reserving the \$[0-9]+ space as bind variables, but it is possible, though unlikely, that users have been naming their variables like that.

It's unclear from your example if that's what you meant, or if you wanted actual named variables ($name, $timestamp_before, $x).

Actual named variables might cause problems with    CREATE FUNCTION AS ... $body$ ... $body$; as well as the need to deduplicate them.

So while it is less seamless, I do like the \bind x y z \g idea because it requires no changes in variable interpolation, and the list can be terminated with a slash command or ;

To your point about forcing extended query protocol even when no parameters are, that would be SELECT 1 \bind \g

It hasn't been discussed, but the question of how to handle output parameters seems fairly straightforward: the value of the bind variable is the name of the psql variable to be set a la \gset.






 

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Maciek Sakrejda
Дата:
Сообщение: Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?)
Следующее
От: Pavel Luzanov
Дата:
Сообщение: Re: Add proper planner support for ORDER BY / DISTINCT aggregates