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

From Merlin Moncure
Subject Re: Assert single row returning SQL-standard functions
Date
Msg-id CAHyXU0wNeGC3xFHcsx=n+6s_yXNKFCCcY1QCvUDUuknf0E2Cyg@mail.gmail.com
Whole thread Raw
In response to Re: Assert single row returning SQL-standard functions  ("David G. Johnston" <david.g.johnston@gmail.com>)
List pgsql-hackers


On Fri, Aug 29, 2025 at 11:45 AM David G. Johnston <david.g.johnston@gmail.com> wrote:
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.

sure, it's off topic to the main question, but it was noted in the intro.

The query in the atomic sql function behaves no differently than an equivalent view.  OIDs don't care about search_path.

roger.

merlin

pgsql-hackers by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: Assert single row returning SQL-standard functions
Next
From: Tom Lane
Date:
Subject: Re: Assert single row returning SQL-standard functions