Re: Converting built-in SQL functions to new style - Mailing list pgsql-hackers

From Noah Misch
Subject Re: Converting built-in SQL functions to new style
Date
Msg-id 20210416083058.GC1365702@rfd.leadboat.com
Whole thread Raw
In response to Converting built-in SQL functions to new style  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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.



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: fix old confusing JSON example
Next
From: Amit Kapila
Date:
Subject: Re: Truncate in synchronous logical replication failed