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
18 matches
Mail list logo
