Re: Allow any[] as input arguments for sql/plpgsql functions to mimic format()

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: Allow any[] as input arguments for sql/plpgsql functions to mimic format()
Дата
Msg-id CAFj8pRAnafRnWs0Jn4tE+MLb_y8YOKZt3KznJkqLTSbQuUORzA@mail.gmail.com
обсуждение исходный текст
Ответ на Allow any[] as input arguments for sql/plpgsql functions to mimicformat()  (Michał "phoe" Herda <phoe@disroot.org>)
Ответы Re: Allow any[] as input arguments for sql/plpgsql functions to mimicformat()  (Michał "phoe" Herda <phoe@disroot.org>)
Список pgsql-hackers
Hi

po 22. 4. 2019 v 11:27 odesílatel Michał "phoe" Herda <phoe@disroot.org> napsal:
Hey everyone,

I am writing a plpgsql function that (to greatly simplify) raises an
exception with a formatted* message. Ideally, I should be able to call
it with raise_exception('The person %I has only %I bananas.', 'Fred',
8), which mimics the format(text, any[]) calling convention.

Here is where I have encountered a limitation of PostgreSQL's design:
https://www.postgresql.org/docs/11/datatype-pseudo.html mentions
explicitly that, "At present most procedural languages forbid use of a
pseudo-type as an argument type".

My reasoning is that I should be able to accept a value of some type if
all I do is passing it to a function that accepts exactly that type,
such as format(text, any[]). Given the technical reality, I assume that
I wouldn't be able to do anything else with that value, but that is
fine, since I don't have to do anything with it regardless.

BR
Michał "phoe" Herda

*I do not want to use the obvious solution of
raise_exception(format(...)) because the argument to that function is
the error ID that is then looked up in a table from which the error
message and sqlstate are retrieved. My full code is in the attached SQL
file. Once it is executed:

SELECT gateway_error('user_does_not_exist', '2'); -- works but is unnatural,
SELECT gateway_error('user_does_not_exist', 2); -- is natural but
doesn't work.

It is known problem, and fix is not easy.

Any expressions inside plpgsql are simple queries like SELECT expr, and they are executed same pipeline like queries.

The plans of these queries are stored and reused. Originally these plans disallow any changes, now some changes are supported, but parameters should be same all time. This is ensured by disallowing "any" type.

Other polymorphic types are very static, so there is not described risk.

Probably some enhancement can be in this are. The plan can be re-planed after some change - but it can has lot of performance impacts. It is long open topic. Some changes in direction to dynamic languages can increase cost of  some future optimization to higher performance :-(.

Regards

Pavel



 

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

Предыдущее
От: Amit Langote
Дата:
Сообщение: display of variables in EXPLAIN VERBOSE
Следующее
От: Kuntal Ghosh
Дата:
Сообщение: Regression test PANICs with master-standby setup on same machine