From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(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:49:15 |
Message-ID: | CAHyXU0wNeGC3xFHcsx=n+6s_yXNKFCCcY1QCvUDUuknf0E2Cyg@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Aug 29, 2025 at 11:45 AM David G. Johnston <
david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
> 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.
>
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2025-08-29 18:07:17 | Re: Assert single row returning SQL-standard functions |
Previous Message | David G. Johnston | 2025-08-29 17:44:29 | Re: Assert single row returning SQL-standard functions |