> Jan might remember more about his thought process here, but I'm thinking > that he copied the SELECT-must-have-INTO rule and then chose to invent > a new statement for the case of wanting to discard the result. I think > you could make an argument for that being good from an oversight-detection > standpoint, but it's not a really strong argument. Particularly in view > of the difficulty we'd have in supporting WITH ... PERFORM ... nicely, > it doesn't seem unreasonable to just allow SELECT-without-INTO.
For my own part, I have to correct forgetting to substitute "PERORM" for "SELECT" around 200 times each major PL/pgSQL project. So it would be user-friendly for it to go away.
But it can have a different reason. In T-SQL (Microsoft or Sybase) or MySQL a unbound query is used to direct transfer data to client side.
There
BEGIN
SELECT 10;
END;
doesn't mean "ignore result of query", but it means push result to client.
And we doesn't support this functionality, so I prefer doesn't allow this syntax.
From:
Amit Kapila Date: Subject:
Re: ALTER SYSTEM SET command to change postgresql.conf parameters
(RE: Proposal for Allow postgresql.conf values to be changed via
SQL [review])
Есть вопросы? Напишите нам!
Соглашаюсь с условиями обработки персональных данных
✖
By continuing to browse this website, you agree to the use of cookies. Go to Privacy Policy.
