On 3/30/21 8:17 PM, Joe Conway wrote:
On 3/30/21 6:22 PM, Tom Lane wrote:
Joe Conway writes:
Heh, I missed the forest for the trees it seems.
That version undid the changes fixing what Ian was originally complaining about.
Duh, right. It would be a good idea for there to be a code comment
e
On 3/30/21 6:22 PM, Tom Lane wrote:
Joe Conway writes:
Heh, I missed the forest for the trees it seems.
That version undid the changes fixing what Ian was originally complaining about.
Duh, right. It would be a good idea for there to be a code comment
explaining this, because it's *far* from
Joe Conway writes:
> Heh, I missed the forest for the trees it seems.
> That version undid the changes fixing what Ian was originally complaining
> about.
Duh, right. It would be a good idea for there to be a code comment
explaining this, because it's *far* from obvious. Say like
* Ch
On 3/30/21 3:37 PM, Joe Conway wrote:
On 3/21/21 12:27 PM, Tom Lane wrote:
I think we may have to adjust the acl.c APIs, or maybe better provide new
entry points, so that we can have variants of pg_xxx_aclcheck that won't
throw a hard error upon not finding the row. We cheesily tried to avoid
a
Joe Conway writes:
> On 3/21/21 12:27 PM, Tom Lane wrote:
>> I think we may have to adjust the acl.c APIs, or maybe better provide new
>> entry points, so that we can have variants of pg_xxx_aclcheck that won't
>> throw a hard error upon not finding the row. We cheesily tried to avoid
>> adjustin
On 3/21/21 12:27 PM, Tom Lane wrote:
I think we may have to adjust the acl.c APIs, or maybe better provide new
entry points, so that we can have variants of pg_xxx_aclcheck that won't
throw a hard error upon not finding the row. We cheesily tried to avoid
adjusting those APIs to support the sema
Joe Conway writes:
> On 3/16/21 2:45 PM, Joe Conway wrote:
>> Ian, or anyone else, any comments/complaints on my changes? If not I will
>> commit
>> and push that version sooner rather than later.
I took a quick look, and I'm afraid I don't believe this:
!* We have to check for dropped
On 3/16/21 2:45 PM, Joe Conway wrote:
Ian, or anyone else, any comments/complaints on my changes? If not I will commit
and push that version sooner rather than later.
Any thoughts on back-patching this?
On one hand, in my view it is clearly a bug. On the other hand, no one has
complained befo
On 3/16/21 1:42 AM, Chengxi Sun wrote:
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:not tested
I tested the patch and it wo
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:not tested
I tested the patch and it works well. And according to the comment,
On 3/7/21 2:35 PM, Zhihong Yu wrote:
> Joe:
> I don't seem to find attachment.
>
> Maybe attach again ?
Oops -- I did forget that, didn't I. This time patch is attached :-)
Joe
--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Sour
Joe:
I don't seem to find attachment.
Maybe attach again ?
Thanks
On Sun, Mar 7, 2021 at 11:12 AM Joe Conway wrote:
> On 3/3/21 9:43 AM, Joe Conway wrote:
> > On 3/3/21 8:50 AM, David Steele wrote:
> >> On 1/29/21 4:56 AM, Joe Conway wrote:
> >>> On 1/29/21 12:13 AM, Ian Lawrence Barwick wrote
On 3/3/21 9:43 AM, Joe Conway wrote:
> On 3/3/21 8:50 AM, David Steele wrote:
>> On 1/29/21 4:56 AM, Joe Conway wrote:
>>> On 1/29/21 12:13 AM, Ian Lawrence Barwick wrote:
2021年1月28日(木) 17:18 Peter Eisentraut:
I'm not convinced the current behavior is wrong. Is there some
On 3/3/21 8:50 AM, David Steele wrote:
> On 1/29/21 4:56 AM, Joe Conway wrote:
>> On 1/29/21 12:13 AM, Ian Lawrence Barwick wrote:
>>> 2021年1月28日(木) 17:18 Peter Eisentraut:
>>> I'm not convinced the current behavior is wrong. Is there some
>>> practical use case that is affected by this
On 1/29/21 4:56 AM, Joe Conway wrote:
On 1/29/21 12:13 AM, Ian Lawrence Barwick wrote:
2021年1月28日(木) 17:18 Peter Eisentraut:
I'm not convinced the current behavior is wrong. Is there some
practical use case that is affected by this behavior?
I was poking around at the function with
On 1/29/21 12:13 AM, Ian Lawrence Barwick wrote:
> 2021年1月28日(木) 17:18 Peter Eisentraut:
> I'm not convinced the current behavior is wrong. Is there some
> practical use case that is affected by this behavior?
>
>
> I was poking around at the function with a view to using it for somethi
2021年1月28日(木) 17:18 Peter Eisentraut :
> On 2021-01-12 06:53, Ian Lawrence Barwick wrote:
> > postgres=# SELECT has_column_privilege('foo', 999::int2, 'SELECT');
> > has_column_privilege
> > --
> > t
> > (1 row)
> >
> > The comment on the relevant cod
On 2021-01-12 06:53, Ian Lawrence Barwick wrote:
postgres=# SELECT has_column_privilege('foo', 999::int2, 'SELECT');
has_column_privilege
--
t
(1 row)
The comment on the relevant code section in "src/backend/utils/adt/acl.c"
(related to "column_priv
Greetings
Consider a table set up as follows:
CREATE TABLE foo (id INT, val TEXT);
ALTER TABLE foo DROP COLUMN val;
When specifying the name of a dropped or non-existent column, the function
"has_column_privilege()" works as expected:
postgres=# SELECT has_column_privilege('foo', 'v
19 matches
Mail list logo
