Re: pg_catalog.pg_proc procedure has correct proargnames array, but proargtypes is empty

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Walker Philips <wphilips53(at)gmail(dot)com>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: pg_catalog.pg_proc procedure has correct proargnames array, but proargtypes is empty
Date: 2022-07-16 00:45:27
Message-ID: 3546148.1657932327@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Walker Philips <wphilips53(at)gmail(dot)com> writes:
> The following function's metadata is not correctly reported in the pg_proc
> table (see picture below).

Looks fine to me:

regression=# CREATE OR REPLACE FUNCTION get_period_type_adjustment(period_type_id
integer)
RETURNS numeric
...
regression=# \x
Expanded display is on.
regression=# select * from pg_proc where proname = 'get_period_type_adjustment';
...
pronargs | 1
pronargdefaults | 0
prorettype | 1700
proargtypes | 23
proallargtypes |
proargmodes |
proargnames | {period_type_id}
proargdefaults |
...

One IN integer argument named period_type_id, result type numeric.

Note the comments in

https://www.postgresql.org/docs/devel/catalog-pg-proc.html

that proallargtypes etc. are generally set to NULL if they wouldn't
carry any additional data. This is a choice we made a long time
ago to prioritize storage space over simplicity of implementation.
I don't know whether we'd make the same choice in a green field
today ... but we're not going to change it now, because the ensuing
confusion would be pretty bad.

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2022-07-16 00:54:58 Re: pg_catalog.pg_proc procedure has correct proargnames array, but proargtypes is empty
Previous Message David Rowley 2022-07-16 00:41:04 Re: pg_catalog.pg_proc procedure has correct proargnames array, but proargtypes is empty