Important textfile!
Title: VIRUS INFECTION ALERT
VIRUS INFECTION ALERT
The WebShield® e500 Appliance discovered a virus in this file.
The file was not cleaned and has been removed.
See your system administrator for further information.
File name: Textfile.zip
Virus name: W32/[EMAIL PROTECTED]
"Nicolas Addington" <[EMAIL PROTECTED]> writes:
> PostgreSQL version: 8.0
tsk, tsk --- it's not 8.0. Yet.
> When a pl/perl trigger for an insert event changes an integer column in the
> new row to null, it fails. Interestingly, it doesn't have a problem if the
> column was originally null.
Loo
Michael Fuhr <[EMAIL PROTECTED]> writes:
> On Tue, Jan 11, 2005 at 12:25:31AM -0500, Tom Lane wrote:
>> A related point is that ALTER TABLE ... OWNER does not recurse to
>> the table's indexes.
> Eh? ALTER TABLE ... OWNER won't touch the indexes if the table
> owner doesn't change, but if the tab
On Tue, Jan 11, 2005 at 12:25:31AM -0500, Tom Lane wrote:
> A related point is that ALTER TABLE ... OWNER does not recurse to
> the table's indexes.
Eh? ALTER TABLE ... OWNER won't touch the indexes if the table
owner doesn't change, but if the table owner changes then so do
the index owners. I
Michael Fuhr <[EMAIL PROTECTED]> writes:
> On Mon, Jan 10, 2005 at 07:28:52PM -0700, Michael Fuhr wrote:
>> pg_dump fails to set ownership on indexes.
> Is this a bug in pg_dump, or is it perhaps a bug in CREATE INDEX?
> Is there any reason CREATE INDEX shouldn't set the index owner to
> be the sa
The following bug has been logged online:
Bug reference: 1381
Logged by: Nicolas Addington
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0
Operating system: aix
Description:invalid input syntax for integer: ""
Details:
When a pl/perl trigger for an insert e
On Mon, Jan 10, 2005 at 07:28:52PM -0700, Michael Fuhr wrote:
> pg_dump fails to set ownership on indexes.
Is this a bug in pg_dump, or is it perhaps a bug in CREATE INDEX?
Is there any reason CREATE INDEX shouldn't set the index owner to
be the same as the table owner?
For pg_dump's part, it's
PostgreSQL 8.0.0rc4
pg_dump fails to set ownership on indexes. When a database superuser
restores a dump, indexes will be owned by the superuser instead of
by the table's owner. The table owner will then be unable to drop
or alter the index.
Here's how to reproduce:
createuser -Upostgres -PAD