On Wed, Mar 10, 2010 at 8:20 AM, Robert Haas wrote:
> On Tue, Mar 9, 2010 at 11:02 AM, Tom Lane 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
On Tue, Mar 9, 2010 at 11:02 AM, Tom Lane 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 as such, but i
On Sun, Mar 7, 2010 at 12:08 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Mar 5, 2010 at 5:32 PM, Tom Lane 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.
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 exa
Chris Travers writes:
> I think this behavior is unexpected, but not a bug. The best fix is
> documenting the datatype better. Something like adding a paragraph to
> chapter 38.9 just above the examples (going off the 8.4 docs):
> Please note, NEW and OLD records are not guaranteed to follow th
On Tue, Mar 9, 2010 at 7:31 AM, Pavel Stehule wrote:
> 2010/3/9 Tom Lane :
>> Robert Haas 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 co
2010/3/9 Tom Lane :
> Robert Haas 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 unspeci
Robert Haas 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 the function text.
Th
Accidentally replied to Tom directly. Sending to the list now.
On Sun, Mar 7, 2010 at 9:08 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Mar 5, 2010 at 5:32 PM, Tom Lane wrote:
>>> It's arguably a bug, but since we lack consensus on whether NULL and
>>> ROW(NULL,NULL,...) are the same t
Robert Haas writes:
> On Fri, Mar 5, 2010 at 5:32 PM, Tom Lane 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 somehow document why this happens?
On Sat, Mar 6, 2010 at 2:12 AM, Chris Travers wrote:
> On Fri, Mar 5, 2010 at 2:32 PM, Tom Lane wrote:
> > Robert Haas writes:
> >>> On Wed, Mar 3, 2010 at 9:53 PM, Robert Haas
> wrote:
> >>> It does seem weird that assigning NEW to var changes the value; I'm
> >>> not sure why that happens. I
On Fri, Mar 5, 2010 at 5:32 PM, Tom Lane wrote:
> Robert Haas writes:
>>> On Wed, Mar 3, 2010 at 9:53 PM, Robert Haas 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 Fri, Mar 5, 2010 at 2:32 PM, Tom Lane wrote:
> Robert Haas writes:
>>> On Wed, Mar 3, 2010 at 9:53 PM, Robert Haas 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
Robert Haas writes:
>> On Wed, Mar 3, 2010 at 9:53 PM, Robert Haas 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 bug?
It's arguably a bug, but sinc
2010/3/3 Oleg Serov :
> I'm asking to fix this =)
>
> On Wed, Mar 3, 2010 at 9:53 PM, Robert Haas 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 bug?
.
I'm asking to fix this =)
On Wed, Mar 3, 2010 at 9:53 PM, Robert Haas wrote:
> 2010/3/3 Oleg Serov :
> >
> >
> > 2010/3/1 Robert Haas
> >>
> >> 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
> >>
2010/3/3 Oleg Serov :
>
>
> 2010/3/1 Robert Haas
>>
>> 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://wik
2010/3/1 Robert Haas
>
> 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_repo
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
2010/2/2
Up!, Anybody will answer on this bugreport?
On Fri, Sep 26, 2008 at 2:57 PM, Oleg Serov 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,
>"type2" V
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",
CONSTRA
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);
CRE
22 matches
Mail list logo
