Re: Converting built-in SQL functions to new style

From: Noah Misch <noah(at)leadboat(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
Subject: Re: Converting built-in SQL functions to new style
Date: 2021-04-16 08:30:58
Message-ID: 20210416083058.GC1365702@rfd.leadboat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Apr 15, 2021 at 07:25:39PM -0400, Tom Lane wrote:
> Here's a draft patch that converts all the built-in and information_schema
> SQL functions to new style, except for half a dozen that cannot be
> converted because they use polymorphic arguments.

This patch looks good.

> One thing I was wondering about, but did not pull the trigger on
> here, is whether to split off the function-related stuff in
> system_views.sql into a new file "system_functions.sql", as has
> long been speculated about by the comments in system_views.sql.
> I think it is time to do this because
>
> (a) The function stuff now amounts to a full third of the file.

Fair.

> (b) While the views made by system_views.sql are intentionally
> not pinned, the function-related commands are messing with
> pre-existing objects that *are* pinned. This seems quite
> confusing to me, and it might interfere with the intention that
> you could reload the system view definitions using this file.

I'm not aware of that causing a problem. Currently, the views give a few
errors, and the functions do not.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2021-04-16 08:50:06 Re: Truncate in synchronous logical replication failed
Previous Message Michael Paquier 2021-04-16 08:00:27 Re: fix old confusing JSON example