On Tue, Mar 9, 2010 at 11:02 AM, Tom Lane t...@sss.pgh.pa.us wrote:
We may need to document it, but not like that; it's (a) incorrect and
(b) unhelpful to the reader, who is left without any clear idea of what
to avoid. I think that the real issue here doesn't have anything to do
with NEW/OLD
On Wed, Mar 10, 2010 at 8:20 AM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Mar 9, 2010 at 11:02 AM, Tom Lane t...@sss.pgh.pa.us wrote:
We may need to document it, but not like that; it's (a) incorrect and
(b) unhelpful to the reader, who is left without any clear idea of what
to avoid.
2010/3/9 Tom Lane t...@sss.pgh.pa.us:
Robert Haas robertmh...@gmail.com writes:
What seems odd to me is that NEW is apparently some other kind of
thing that is not the same kind of thing as the row variable.
NEW is a record variable, not a row variable. In this context that's
sensible
On Tue, Mar 9, 2010 at 7:31 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
2010/3/9 Tom Lane t...@sss.pgh.pa.us:
Robert Haas robertmh...@gmail.com writes:
What seems odd to me is that NEW is apparently some other kind of
thing that is not the same kind of thing as the row variable.
NEW is
Robert Haas robertmh...@gmail.com writes:
What seems odd to me is that NEW is apparently some other kind of
thing that is not the same kind of thing as the row variable.
NEW is a record variable, not a row variable. In this context that's
sensible because its actual rowtype is unspecified by
I wrote:
I think that the real issue here doesn't have anything to do
with NEW/OLD as such, but is related to the representational difference
between record and row variables.
BTW, just to reinforce that it's not NEW/OLD that's the issue, here's
a simplified version of Oleg's non-trigger
On Sun, Mar 7, 2010 at 12:08 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Mar 5, 2010 at 5:32 PM, Tom Lane t...@sss.pgh.pa.us wrote:
It's arguably a bug, but since we lack consensus on whether NULL and
ROW(NULL,NULL,...) are the same thing, it's
Robert Haas robertmh...@gmail.com writes:
On Fri, Mar 5, 2010 at 5:32 PM, Tom Lane t...@sss.pgh.pa.us wrote:
It's arguably a bug, but since we lack consensus on whether NULL and
ROW(NULL,NULL,...) are the same thing, it's difficult to make a
bulletproof case either way.
Have we or can we
Accidentally replied to Tom directly. Sending to the list now.
On Sun, Mar 7, 2010 at 9:08 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Mar 5, 2010 at 5:32 PM, Tom Lane t...@sss.pgh.pa.us wrote:
It's arguably a bug, but since we lack consensus on
On Sat, Mar 6, 2010 at 2:12 AM, Chris Travers ch...@metatrontech.comwrote:
On Fri, Mar 5, 2010 at 2:32 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Mar 3, 2010 at 9:53 PM, Robert Haas robertmh...@gmail.com
wrote:
It does seem weird that
2010/3/3 Oleg Serov sero...@gmail.com:
I'm asking to fix this =)
On Wed, Mar 3, 2010 at 9:53 PM, Robert Haas robertmh...@gmail.com wrote:
It does seem weird that assigning NEW to var changes the value; I'm
not sure why that happens. Is that what you're asking about?
Anyone else have an
Robert Haas robertmh...@gmail.com writes:
On Wed, Mar 3, 2010 at 9:53 PM, Robert Haas robertmh...@gmail.com wrote:
It does seem weird that assigning NEW to var changes the value; I'm
not sure why that happens. Is that what you're asking about?
Anyone else have an opinion on whether this is a
On Fri, Mar 5, 2010 at 2:32 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Mar 3, 2010 at 9:53 PM, Robert Haas robertmh...@gmail.com wrote:
It does seem weird that assigning NEW to var changes the value; I'm
not sure why that happens. Is that what
On Fri, Mar 5, 2010 at 5:32 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Mar 3, 2010 at 9:53 PM, Robert Haas robertmh...@gmail.com wrote:
It does seem weird that assigning NEW to var changes the value; I'm
not sure why that happens. Is that what
2010/3/1 Robert Haas robertmh...@gmail.com
It's not obvious whether this is the same as one of the various other
problems you've complained about. If it isn't, an English description
of what you think the problem is would probably improve your odds.
See also:
2010/3/3 Oleg Serov sero...@gmail.com:
2010/3/1 Robert Haas robertmh...@gmail.com
It's not obvious whether this is the same as one of the various other
problems you've complained about. If it isn't, an English description
of what you think the problem is would probably improve your odds.
I'm asking to fix this =)
On Wed, Mar 3, 2010 at 9:53 PM, Robert Haas robertmh...@gmail.com wrote:
2010/3/3 Oleg Serov sero...@gmail.com:
2010/3/1 Robert Haas robertmh...@gmail.com
It's not obvious whether this is the same as one of the various other
problems you've complained
It's not obvious whether this is the same as one of the various other
problems you've complained about. If it isn't, an English description
of what you think the problem is would probably improve your odds.
See also:
http://wiki.postgresql.org/wiki/Guide_to_reporting_problems
...Robert
Up!, Anybody will answer on this bugreport?
On Fri, Sep 26, 2008 at 2:57 PM, Oleg Serov sero...@gmail.com wrote:
Sorry, bug is not in triggers, it is in PL/PGSQL var assign mechanism
here it is an example:
ROLLBACK;
BEGIN;
CREATE TYPE composite_type AS (
type VARCHAR,
SQL code:
ROLLBACK;
BEGIN;
CREATE TYPE composite_type AS (
typename VARCHAR
);
CREATE TABLE buggy (
id BIGINT NOT NULL,
bug composite_type,
CONSTRAINT buggy_pkey PRIMARY KEY(id)
) WITH OIDS;
INSERT INTO buggy (id, bug) VALUES
(100196418052926086, NULL);
CREATE OR REPLACE
Sorry, bug is not in triggers, it is in PL/PGSQL var assign mechanism
here it is an example:
ROLLBACK;
BEGIN;
CREATE TYPE composite_type AS (
type VARCHAR,
type2 VARCHAR
);
CREATE TABLE buggy (
id BIGINT NOT NULL,
bug composite_type,
CONSTRAINT
The following bug has been logged online:
Bug reference: 1620
Logged by: Nahuel Greco
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.4.7
Operating system: Debian unstable i386
Description:triggers breaks with alter table (at least with
plpythonu)
Details:
Eugene Gridasov ([EMAIL PROTECTED]) reports a bug with a severity of 1
The lower the number the more severe it is.
Short Description
triggers do not execute in right order in procedures
Long Description
The constraint trigger on delete executes ONLY after procedure
completion, but it does not
Søren laursen ([EMAIL PROTECTED]) reports a bug with a severity of 2
The lower the number the more severe it is.
Short Description
triggers tablename are not rename if table are renamed.
Long Description
I had a database where I during development created a new table to test a new design.
On
[EMAIL PROTECTED] writes:
triggers tablename are not rename if table are renamed.
7.2 does this correctly.
regards, tom lane
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
25 matches
Mail list logo
