At 23:20 14/10/00 -0700, Stephan Szabo wrote:
>
>Well, actually the question of whether failing referential actions
>due to permission deficits of the user doing the delete/update
>on the pk table is a bug or feature still stands. It would be
>fairly trivial to extend Peter's patch to effectively
Well, actually the question of whether failing referential actions
due to permission deficits of the user doing the delete/update
on the pk table is a bug or feature still stands. It would be
fairly trivial to extend Peter's patch to effectively setuid on
the actions, but the question is whether
Oh, OK. I will forget it.
>
> Actually Peter did a patch for this fairly recently I
> believe. I haven't grabbed CVS recently enough to know
> if it got committed. There's a related question of what
> permissions you need to follow referential actions (currently
> it's the same permission as
Actually Peter did a patch for this fairly recently I
believe. I haven't grabbed CVS recently enough to know
if it got committed. There's a related question of what
permissions you need to follow referential actions (currently
it's the same permission as if you were doing the implied
statement
Can someone give me a good description of this for TODO?
>
> Yes, this is a known issue due to the fact that the
> triggers use SPI and need to use SELECT ... FOR UPDATE
> to lock the rows it is reading (and select for update
> requires the update permission). The workaround I
> know about for
On Tue, 22 Aug 2000 [EMAIL PROTECTED] wrote:
> James Aspnes ([EMAIL PROTECTED]) reports a bug with a severity of 2
> The lower the number the more severe it is.
>
> Short Description
> checking foreign keys requires write access
>
> Long Description
> In version 7.0.2, create tables A and B wh
[EMAIL PROTECTED] writes:
> The backend call lseek much more often than it has to.
Denis Perchine fixed this a couple of months ago. You might care to
repeat your experiments with current sources (see our CVS server, or
the nightly snapshot tarball on our FTP server). If there's still
a problem
[EMAIL PROTECTED] writes:
> When trying to list/describe ( \d )
> ERROR: getattproperties: no attribute tuple 1259 -2
Sounds pretty thoroughly hosed ... but there's not enough info here
to diagnose the problem. Is this a fresh install, or an installation
that had been working for a while and
Yes, this is a known issue due to the fact that the
triggers use SPI and need to use SELECT ... FOR UPDATE
to lock the rows it is reading (and select for update
requires the update permission). The workaround I
know about for now is to give update permission and make
triggers to disallow updates
[EMAIL PROTECTED] writes:
> When performing a query against a table that has a 64bit (int8)
> primary key a sequential scan always takes place.
Possibly a casting issue. Observe:
regression=# create table foo1 (f1 int8 primary key);
NOTICE: CREATE TABLE/PRIMARY KEY will create implicit index '
Unprivileged user <[EMAIL PROTECTED]> writes:
> The backend crash after seeing a message 'NOTICE: trying to delete
> portal name that does not exist' after using a cursor on a particular
> query (which'll be shown below).
Oooh, that's a nasty one! The problem is one of bogus memory management
fo
11 matches
Mail list logo
