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
Doug Mitchell ([EMAIL PROTECTED]) reports a bug with a severity of 3
The lower the number the more severe it is.
Short Description
Excessive seeking by backend
Long Description
The backend call lseek much more often than it has to. The storage manage should not
do either of the following:
1.
[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
chris vale ([EMAIL PROTECTED]) reports a bug with a severity of 2
The lower the number the more severe it is.
Short Description
psql list ( \d ) command returns error
Long Description
Using 7.0.2 on LinuxPPC (YellowDog ) and RPMS's from postgresql.org.
When trying to list/describe ( \d )
ERR
[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 '
() reports a bug with a severity of 2
The lower the number the more severe it is.
Short Description
Your bug system shows misformatted bug description and 'example code'
Long Description
When you show long description of the bug
tag should be used in order to show text
as it was entered
Samp
Stu Coates ([EMAIL PROTECTED]) reports a bug with a severity of 2
The lower the number the more severe it is.
Short Description
Not performing index scan for 64bit primary
Long Description
When performing a query against a table that has a 64bit (int8) primary key a
sequential scan always takes
NAGY Andras ([EMAIL PROTECTED]) reports a bug with a severity of 3
The lower the number the more severe it is.
Short Description
Foreign keys referencing read-only tables fail
Long Description
Consider two tables, foo(barid) and bar(id, str), where foo has a foreign key
referencing bar(id). It
Gregg Wonderly ([EMAIL PROTECTED]) reports a bug with a severity of 1
The lower the number the more severe it is.
Short Description
JDBC driver broken for ResultSet.getTimeStamp()
Long Description
The JDBC driver in 7.0.2 uses Timestamp.toString() to create the string representation
of the time
Mickael FEYS ([EMAIL PROTECTED]) reports a bug with a severity of 2
The lower the number the more severe it is.
Short Description
Unexpected behaviour of the ecpg -D option.
Long Description
Configuration :
system : sun sparc ultra 5
os : solaris 2.7
postgres : 7.0.2
compilator : cc com
Jon Peatfield ([EMAIL PROTECTED]) reports a bug with a severity of 4
The lower the number the more severe it is.
Short Description
Docs use wrong chars
Long Description
In the ps docs several characters print out incorrectly, e.g. pi, sigma etc since the
font being used doesn't have those glyph
fmatheus ([EMAIL PROTECTED]) reports a bug with a severity of 3
The lower the number the more severe it is.
Short Description
trouble with COPY from a iso-8859-1 encoding file
Long Description
Im notice this in pg 6.5.3 in a Debian/linux 2.2 in AMD K7.
if there is some enhancede char like a a a
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 where B has a foreign
key reference to A. Grant user X insert ac
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
Chi Fan ([EMAIL PROTECTED]) reports a bug with a severity of 2
The lower the number the more severe it is.
Short Description
pgsql 7.0.2 cursor bug
Long Description
POSTGRESQL BUG REPORT TEMPLATE
Vinny ([EMAIL PROTECTED]) reports a bug with a severity of 1
The lower the number the more severe it is.
Short Description
There's this bug, see?
Long Description
It's a huge bug that's eating tons of memory.
Sample Code
for(x=0;x<10;x++)
p[x] = malloc(1);
No file was uploaded with t
23 matches
Mail list logo
