Re: Assert single row returning SQL-standard functions

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Merlin Moncure <mmoncure(at)gmail(dot)com>
Cc: Joel Jacobson <joel(at)compiler(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Assert single row returning SQL-standard functions
Date: 2025-08-29 17:44:29
Message-ID: CAKFQuwa1RSoCyxJr1mnp7ahbO4DC_g4w-MTnQw2cVh6Vx8QKkw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Aug 29, 2025 at 10:34 AM Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:

> On Fri, Aug 29, 2025 at 1:03 AM Joel Jacobson <joel(at)compiler(dot)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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Merlin Moncure 2025-08-29 17:49:15 Re: Assert single row returning SQL-standard functions
Previous Message Merlin Moncure 2025-08-29 17:34:27 Re: Assert single row returning SQL-standard functions