On Sat, Mar 6, 2010 at 2:12 AM, Chris Travers <chris@metatrontech.com>wrote:
> On Fri, Mar 5, 2010 at 2:32 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Robert Haas <robertmhaas@gmail.com> writes:
> >>> On Wed, Mar 3, 2010 at 9:53 PM, Robert Haas <robertmhaas@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 bug?
> >
> > 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. In any case nothing is likely to get done
> > about it in the near term because it's wired into plpgsql's
> > implementation. Changing from row to record representation of such
> > variables is possible but would probably have side effects, ie, it would
> > create new compatibility issues of unknown seriousness. I'm not too
> > optimistic about the performance implications either.
>
> I don't know if it is a bug. Different textual representations could
> easily happen due to intermediate conversions of datatypes....
>
> For example: I wouldn't expect timestamp::date::text to equal
> timestamp::text. Textual representations are not necessarily
> consistent.
>
> I guess a better question for Oleg might be:
>
> "Why is it important to you to get this fixed? What are you trying to
> do that you can't do without fixing this?"
>
This bug is not critical, i'm comparing two rows with single structure. and
i cast it to text and compare.
>
> Best Wishes,
> Chris Travers
>
> --
> Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-bugs
>
--=20
=F3 =D5=D7=C1=D6=C5=CE=C9=C5=CD
=EF=CC=C5=C7 =F3=C5=D2=CF=D7
