Re: Converting built-in SQL functions to new style
Noah Misch <noah@leadboat.com>
From: Noah Misch <noah@leadboat.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andrew Dunstan <andrew@dunslane.net>, Robert Haas <robertmhaas@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Date: 2021-04-16T08:30:58Z
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.
Commits
-
Update dummy prosrc values.
- 8a2df442b652 14.0 landed
-
Convert built-in SQL-language functions to SQL-standard-body style.
- 767982e36298 14.0 landed
-
Split function definitions out of system_views.sql into a new file.
- e80949372564 14.0 landed