Re: proposal: plpgsql pragma statement

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: proposal: plpgsql pragma statement
Дата
Msg-id CAFj8pRAZaNDFuEPZGa6p7W3bWKg6ZMTfhr2UdSNJaQPZDou4FA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: proposal: plpgsql pragma statement  (Dmitry Igrishin <dmitigr@gmail.com>)
Список pgsql-hackers


st 5. 12. 2018 v 19:12 odesílatel Dmitry Igrishin <dmitigr@gmail.com> napsal:
вт, 4 дек. 2018 г. в 20:13, Pavel Stehule <pavel.stehule@gmail.com>:
>
> Hi
>
> I wrote plpgsql_check https://github.com/okbob/plpgsql_check.
>
> It is working well, but because it does static analyse only, sometimes it can produces false alarms or it should to stop a analyse, because there are not necessary data.
>
> https://github.com/okbob/plpgsql_check/issues/36
>
> I see one possible solution in introduction of pragma statement with syntax:
>
>   PRAGMA keyword [content to semicolon];
>
> The pragma has a relation to following statement. So the issue 36 can be solved by pragma
>
> PRAGMA cmdtype CREATE;
> EXECUTE format('CREATE TABLE xxx ...
>
> The PRAGMA statement does nothing in runtime. It works only in compile time, and add a pair of key, value to next non pragma statement. This information can be used by some plpgsql extensions.
>
> What do you think about this proposal?
I think it's a good idea in common. But how about multiple PRAGMAs? Consider

  PRAGMA cmdtype CREATE;
  PRAGMA objtype TABLE;
  EXECUTE format('CREATE TABLE');

yes, it is possible. They are assigned to next non pragma statement.

some like

PRAGMA cmdtype SELECT
PRAGMA resulttype (a int, b int, c int)
EXECUTE format('SELECT ... FROM %I ...

PRAGMA tmp_table_query
PRAGMA resulttype (a int, b int, c int)
FOR r IN SELECT * FROM some_temporary_table ...

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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: slow queries over information schema.tables
Следующее
От: Tom Lane
Дата:
Сообщение: Re: slow queries over information schema.tables