Horton

Re: Assert single row returning SQL-standard functions

David G. Johnston <david.g.johnston@gmail.com>

View thread
From: "David G. Johnston" <david.g.johnston@gmail.com>
To: Merlin Moncure <mmoncure@gmail.com>
Cc: Joel Jacobson <joel@compiler.org>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2025-08-29T17:44:29Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Add error_on_null(), checking if the input is the null value

  2. SQL-standard function body

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.