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
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 |