The following bug has been logged online:
Bug reference: 5457
Logged by: Chana Slutzkin
Email address: ch...@cs.huji.ac.il
PostgreSQL version: 8.4
Operating system: FreeBSD 7.2
Description:dblink_connect now restricts non-superusers to password
Details:
dblink in ve
The following bug has been logged online:
Bug reference: 5458
Logged by: Takahiro Itagaki
Email address: itagaki.takah...@oss.ntt.co.jp
PostgreSQL version: 9.0beta1
Operating system: Linux (maybe ALL)
Description:Permission check is skipped by inheritance
Details:
E
On 2010-05-11, Chana Slutzkin wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5457
> Logged by: Chana Slutzkin
> Email address: ch...@cs.huji.ac.il
> PostgreSQL version: 8.4
> Operating system: FreeBSD 7.2
> Description:dblink_connect now restri
Chana Slutzkin wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5457
> Logged by: Chana Slutzkin
> Email address: ch...@cs.huji.ac.il
> PostgreSQL version: 8.4
> Operating system: FreeBSD 7.2
> Description:dblink_connect now restricts non-superu
"Takahiro Itagaki" writes:
> Even if a non-superuser who has no permissions on
> a parent and a child tables, he can retrieve data
> from the parent when the two tables have inheritance
> relationship.
Hmm, the change to not check child permissions is intentional, but
it looks like Peter overdid
On mån, 2010-05-10 at 15:55 +, Bryan Henderson wrote:
> >>> I don't know how concrete you want.
> >
> >Something one can download and compile.
>
> That wouldn't be worth anyone's effort, since the problem is esaily
> enough elucidated with a few words of explanation. I.e. I'm sure you
> can i
On Tue, May 11, 2010 at 1:08 PM, Peter Eisentraut wrote:
> On mån, 2010-05-10 at 15:55 +, Bryan Henderson wrote:
>> >>> I don't know how concrete you want.
>> >
>> >Something one can download and compile.
>>
>> That wouldn't be worth anyone's effort, since the problem is esaily
>> enough eluci
On Tue, May 11, 2010 at 12:42, Robert Haas wrote:
> I guess the question that comes to mind for me is how many other
> things fall into this category. We define a lot of symbols like int4
> and int32 that other people could also have defined, and I don't
> really want to s/^/pg/ all of them. If
Alex Hunsaker writes:
> On Tue, May 11, 2010 at 12:42, Robert Haas wrote:
>> I guess the question that comes to mind for me is how many other
>> things fall into this category. Â We define a lot of symbols like int4
>> and int32 that other people could also have defined, and I don't
>> really wan
On tis, 2010-05-11 at 14:42 -0400, Robert Haas wrote:
> I guess the question that comes to mind for me is how many other
> things fall into this category. We define a lot of symbols like int4
> and int32 that other people could also have defined, and I don't
> really want to s/^/pg/ all of them.
On Tue, May 11, 2010 at 3:47 PM, Tom Lane wrote:
> Alex Hunsaker writes:
>> On Tue, May 11, 2010 at 12:42, Robert Haas wrote:
>>> I guess the question that comes to mind for me is how many other
>>> things fall into this category. We define a lot of symbols like int4
>>> and int32 that other pe
The following bug has been logged online:
Bug reference: 5459
Logged by: Mason Hale
Email address: ma...@onespot.com
PostgreSQL version: 8.3.8
Operating system: Redhat EL 5.1-64 bit
Description:Unable to cancel query while in send()
Details:
ISSUE: unable to cancel
>On the flip side if the code that purports to cope with other
>definitions of bool is useless, we should remove it so as to avoid
>giving the impression that we have any ability to so cope.
Indeed, that code is what led me to believe I could work around my bool
conflict problem with a "#define bo
"Mason Hale" writes:
> ISSUE: unable to cancel queries using pg_cancel_backend(), that are in
> send() function call, waiting on client receipt of data.
I think what you are describing is a kernel bug. There's not a lot
we can do about it if the send() call hangs. Considering the kernel
already
>Yeah, that may well be. I don't think we should have a policy of
>folding our arms and shouting "no" whenever someone asks us to clean
>up our namespace, but on the flip side one request (or even two) is
>probably not enough reason to do anything drastic, and this would be
>fairly drastic.
How a
15 matches
Mail list logo