Re: has_table_privilege for a table in unprivileged schema causes an error

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: has_table_privilege for a table in unprivileged schema causes an error
Date: 2018-08-27 14:26:42
Message-ID: CAKFQuwYtcpYMhuno29gi7-AFujFLo0OGJAJByPfr87qvmH5LTg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Aug 25, 2018 at 8:29 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> There's a backwards-compatibility argument for not changing this behavior,
> sure, but I don't buy the other arguments you made here. And I don't
> think there's all that much to the backwards-compatibility argument,
> considering that the current behavior is to fail.
>

+1; any code using these functions can reasonably be expected to handle
true and false responses. Converting a present error into a false under
that presumption results in similar, and arguably improved, semantics.

While null is something to be avoided generally this is one of those cases
where if we did want to have a "cannot answer the question because
pre-conditions are not met" response I'd strongly consider using null to
represent that response instead of an error - using coalesce is
considerably easier than performing error handling. That isn't an option
here and the while there is information loss involved in the proposed
change its seems worth it to me to make such a change to make using the
function for its primary behavior easier at the cost of a removing a
hard-to-use side effect. Adding a new default argument or function is not
desirable.

To be clear, I do not consider this is not a backpatchable change.

David J.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2018-08-27 14:32:42 Re: some more error location support
Previous Message Peter Eisentraut 2018-08-27 14:25:28 simplify index tuple descriptor initialization