Testing ... please reply - Mailing list pgsql-general

Could someone reply to this email? I am testing my subscription; joined over 2 months ago, but never get any response
toquestions 

Thanks!
Atul



-----Original Message-----
From: pgsql-general-owner@postgresql.org [mailto:pgsql-general-owner@postgresql.org] On Behalf Of Joshua D. Drake
Sent: Wednesday, April 22, 2009 12:56 PM
To: Alvaro Herrera
Cc: S Arvind; pgsql-general@postgresql.org
Subject: Re: [GENERAL] From 8.1 to 8.3

On Wed, 2009-04-22 at 12:49 -0400, Alvaro Herrera wrote:
> S Arvind escribió:
> > Our company wants to move from 8,1 to 8.3 latest. In irc they told me to
> > check realse notes for issues while upgrading. But there are lots of release
> > notesss. Can anyone tell some most noticable change or place-of-error while
> > upgrading?
>
> If you're too lazy to read them, we're too lazy to summarise them for
> you ...
>

And to actually be helpful, the number one issue people see to run into
is this one:

        Non-character data types are no longer automatically cast to
        TEXT (Peter, Tom)

        Previously, if a non-character value was supplied to an operator
        or function that requires text input, it was automatically cast
        to text, for most (though not all) built-in data types. This no
        longer happens: an explicit cast to text is now required for all
        non-character-string types. For example, these expressions
        formerly worked:

        substr(current_date, 1, 4)
        23 LIKE '2%'

        but will now draw "function does not exist" and "operator does
        not exist" errors respectively. Use an explicit cast instead:

        substr(current_date::text, 1, 4)
        23::text LIKE '2%'

        (Of course, you can use the more verbose CAST() syntax too.) The
        reason for the change is that these automatic casts too often
        caused surprising behavior. An example is that in previous
        releases, this expression was accepted but did not do what was
        expected:

        current_date < 2017-11-17

        This is actually comparing a date to an integer, which should be
        (and now is) rejected — but in the presence of automatic casts
        both sides were cast to text and a textual comparison was done,
        because the text < text operator was able to match the
        expression when no other < operator could.

        Types char(n) and varchar(n) still cast to text automatically.
        Also, automatic casting to text still works for inputs to the
        concatenation (||) operator, so long as least one input is a
        character-string type.

However Alvaro is right. You should read the entire incompatibilities
section, and of course test.

Sincerely,

Joshua D. Drake

--
PostgreSQL - XMPP: jdrake@jabber.postgresql.org
   Consulting, Development, Support, Training
   503-667-4564 - http://www.commandprompt.com/
   The PostgreSQL Company, serving since 1997


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.287 / Virus Database: 270.12.1/2070 - Release Date: 04/22/09 08:49:00