Re: Assert single row returning SQL-standard functions
| От | David G. Johnston |
|---|---|
| Тема | Re: Assert single row returning SQL-standard functions |
| Дата | |
| Msg-id | CAKFQuwa1RSoCyxJr1mnp7ahbO4DC_g4w-MTnQw2cVh6Vx8QKkw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Assert single row returning SQL-standard functions (Merlin Moncure <mmoncure@gmail.com>) |
| Ответы |
Re: Assert single row returning SQL-standard functions
|
| Список | pgsql-hackers |
On Fri, Aug 29, 2025 at 10:34 AM Merlin Moncure <mmoncure@gmail.com> wrote:
On Fri, Aug 29, 2025 at 1:03 AM Joel Jacobson <joel@compiler.org> wrote:*) Renaming of database objects seamless, thanks to function body being
parsed at function definition time and stored as expression nodes.How does that work in practice? for current SQL (not pl/pgsql) functions, this will fail:create function f() returns int as $$ create temp table i(i int); select * from i; $$ language sql;ERROR: relation "i" does not exist
This example seems unrelated to the point being made.
Also, how do search_path interactions work in your understanding?
The query in the atomic sql function behaves no differently than an equivalent view. OIDs don't care about search_path.
David J.
В списке pgsql-hackers по дате отправления: