Re: BUG: value in information_schema.parameters.parameter_default is always NULL for roles t

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Vedran Bilopavlović <vbilopav(at)gmail(dot)com>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG: value in information_schema.parameters.parameter_default is always NULL for roles t
Date: 2024-06-09 17:06:20
Message-ID: 541707.1717952780@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

=?UTF-8?Q?Vedran_Bilopavlovi=C4=87?= <vbilopav(at)gmail(dot)com> writes:
> Values in table *information_schema.parameters*, column *parameter_default*,
> are always NULL only for roles that are not superuser.

I see no bug there. The manual defines parameter_default as

The default expression of the parameter, or null if none or if the
function is not owned by a currently enabled role.

A superuser is considered to own everything, but for mere-mortal
roles a result would only appear for functions you own. The
SQL implementation of the view appears to match this definition:

CASE WHEN pg_has_role(proowner, 'USAGE')
THEN pg_get_function_arg_default(p_oid, (ss.x).n)
ELSE NULL END

You could certainly quibble with the value of hiding the information
when it's readily available from our system catalogs --- but this
is a SQL-standard-defined view so we implement it as the standard
says, and this is what the standard says it should do.

> There is a workaround by using pg_proc table:

I'd recommend using something from the pg_get_function*() family.

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Masahiko Sawada 2024-06-10 00:33:50 Re: BUG #18483: Segmentation fault in tests modules
Previous Message Alexander Lakhin 2024-06-09 12:00:00 Re: BUG #18483: Segmentation fault in tests modules