Peter Eisentraut <peter_e@gmx.net> writes:
> This is probably going to blow up when we have the said schema support.
> Probably better to reference things by oid.
Two versions, one that takes an oid and one that takes a name, might be
convenient. The name version will probably have to accept qualified
names (schema.table) once we have schema support --- but I don't think
that needs to break the function definition. An unqualified name would
be looked up using whatever schema resolution rules would be in effect
for ordinary table references.
We might also want the user to be specified by usesysid rather than
name; and a two-parameter form that assumes user == current_user would
be a particularly useful shorthand.
> Also, since things other than
> relations might have privileges sometime, the function name should
> probably imply this; maybe "has_table_privilege".
Agreed.
> * I'm not sure whether it's useful to handle NULL parameters explicitly.
> The common approach is to return NULL, which would be semantically right
> for this function.
The standard approach for C-coded functions is to mark them
'proisstrict' in pg_proc, and then not waste any code checking for NULL;
the function manager takes care of it for you. The only reason not to
do it that way is if you actually want to return non-NULL for (some
cases with) NULL inputs. Offhand this looks like a strict function to
me...
regards, tom lane
