Thomas Munro writes:
> On Thu, Aug 1, 2019 at 8:41 PM Takuma Hoshiai wrote:
>> On Thu, 1 Aug 2019 20:21:57 +1200
>> Thomas Munro wrote:
>>> Based on the above review, I have set this to 'Returned with
>>> feedback'. If you plan to produce a new patch in time for the next
>>> Commitfest in Septe
On Thu, Aug 1, 2019 at 8:41 PM Takuma Hoshiai wrote:
> On Thu, 1 Aug 2019 20:21:57 +1200
> Thomas Munro wrote:
> > Based on the above review, I have set this to 'Returned with
> > feedback'. If you plan to produce a new patch in time for the next
> > Commitfest in September, please let me know v
On Thu, 1 Aug 2019 20:21:57 +1200
Thomas Munro wrote:
> On Wed, Jul 31, 2019 at 4:24 AM Tom Lane wrote:
> > Takuma Hoshiai writes:
> > > [ fix_to_reg_v2.patch ]
> >
> > I took a quick look through this patch. I'm on board with the goal
> > of not having schema-access violations throw an error
On Wed, Jul 31, 2019 at 4:24 AM Tom Lane wrote:
> Takuma Hoshiai writes:
> > [ fix_to_reg_v2.patch ]
>
> I took a quick look through this patch. I'm on board with the goal
> of not having schema-access violations throw an error in these
> functions, but the implementation feels pretty ugly and b
On Tue, 30 Jul 2019 12:24:13 -0400
Tom Lane wrote:
> Takuma Hoshiai writes:
> > [ fix_to_reg_v2.patch ]
>
> I took a quick look through this patch. I'm on board with the goal
> of not having schema-access violations throw an error in these
> functions, but the implementation feels pretty ugly
Takuma Hoshiai writes:
> [ fix_to_reg_v2.patch ]
I took a quick look through this patch. I'm on board with the goal
of not having schema-access violations throw an error in these
functions, but the implementation feels pretty ugly and bolted-on.
Nobody who had designed the code to do this from t
Hi Nagata-san,
sorry for te late reply.
Thank you for your comments, I have attached a patch that reflected it.
On Tue, 19 Mar 2019 15:13:04 +0900
Yugo Nagata wrote:
> I reviewed the patch. Here are some comments:
>
> /*
> + * RangeVarCheckNamespaceAccessNoError
> + * Returns true if
st 20. 3. 2019 v 5:55 odesÃlatel Takuma Hoshiai
napsal:
> On Wed, 20 Mar 2019 09:48:59 +0900 (Tokyo Standard Time)
> Kyotaro HORIGUCHI wrote:
>
> > At Wed, 20 Mar 2019 07:13:28 +0900 (JST), Tatsuo Ishii <
> is...@sraoss.co.jp> wrote in <
> 20190320.071328.48576044685486.t-is...@sraoss.co.jp>
On Wed, 20 Mar 2019 09:48:59 +0900 (Tokyo Standard Time)
Kyotaro HORIGUCHI wrote:
> At Wed, 20 Mar 2019 07:13:28 +0900 (JST), Tatsuo Ishii
> wrote in <20190320.071328.48576044685486.t-is...@sraoss.co.jp>
> > >> I (and Hoshiai-san) concern about following case:
> > >>
> > >> # revoke usage
At Wed, 20 Mar 2019 07:13:28 +0900 (JST), Tatsuo Ishii
wrote in <20190320.071328.48576044685486.t-is...@sraoss.co.jp>
> >> I (and Hoshiai-san) concern about following case:
> >>
> >> # revoke usage on schema s1 from foo;
> >> REVOKE
> >> :
> >> [connect as foo]
> >> test=> select to_regclass
At Tue, 19 Mar 2019 19:09:59 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20190319.190959.25783254.horiguchi.kyot...@lab.ntt.co.jp>
> That works in a transaction. It looks right that the actually
> revoked schema cannot be accessed.
>From another viewpoint, the behavior really doesn
>> I (and Hoshiai-san) concern about following case:
>>
>> # revoke usage on schema s1 from foo;
>> REVOKE
>> :
>> [connect as foo]
>> test=> select to_regclass('s1.t1')::oid;
>> ERROR: permission denied for schema s1
>
> That works in a transaction. It looks right that the actually
> revoked sc
At Tue, 19 Mar 2019 17:54:01 +0900 (JST), Tatsuo Ishii
wrote in <20190319.175401.646838939186238443.t-is...@sraoss.co.jp>
> > It seems to be a different thing. The oid 1647239 would be a
> > table in public schema or any schema that the user has access
> > to. If search_path contained only unpriv
>> You misunderstand the functionality of to_regclass(). Even if a user
>> does not have an access privilege of certain table, to_regclass() does
>> not raise an error.
>>
>> test=> select * from t1;
>> ERROR: permission denied for table t1
>>
>> test=> select to_regclass('t1')::oid;
>> to_regcl
At Tue, 19 Mar 2019 16:35:32 +0900 (JST), Tatsuo Ishii
wrote in <20190319.163532.529526338176696856.t-is...@sraoss.co.jp>
> >> According to the document, "to_reg* functions return null rather than
> >> throwing an error if the name is not found", but this is not the case
> >> if the arguments to
>> According to the document, "to_reg* functions return null rather than
>> throwing an error if the name is not found", but this is not the case
>> if the arguments to those functions are schema qualified and the
>> caller does not have access permission of the schema even if the table
>> (or othe
Hello.
At Thu, 14 Mar 2019 13:37:00 +0900, Takuma Hoshiai wrote
in <20190314133700.c271429ddc00ddab3aac2...@sraoss.co.jp>
> Hi, hackers,
>
> According to the document, "to_reg* functions return null rather than
> throwing an error if the name is not found", but this is not the case
> if the arg
Hi Takuma,
On Thu, 14 Mar 2019 13:37:00 +0900
Takuma Hoshiai wrote:
> Hi, hackers,
>
> According to the document, "to_reg* functions return null rather than
> throwing an error if the name is not found", but this is not the case
> if the arguments to those functions are schema qualified and the
Hi, hackers,
According to the document, "to_reg* functions return null rather than
throwing an error if the name is not found", but this is not the case
if the arguments to those functions are schema qualified and the
caller does not have access permission of the schema even if the table
(or other
19 matches
Mail list logo
