Request a Demo
Home   >   mailing lists

Re: Assert single row returning SQL-standard functions - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: Assert single row returning SQL-standard functions
Date
Msg-id CAKFQuwa1RSoCyxJr1mnp7ahbO4DC_g4w-MTnQw2cVh6Vx8QKkw@mail.gmail.com
Whole thread Raw
In response to Re: Assert single row returning SQL-standard functions  (Merlin Moncure <mmoncure@gmail.com>)
Responses Re: Assert single row returning SQL-standard functions
List pgsql-hackers
Tree view
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 by date:

Previous
From: Merlin Moncure
Date:
Subject: Re: Assert single row returning SQL-standard functions
Next
From: Merlin Moncure
Date:
Subject: Re: Assert single row returning SQL-standard functions