Re: Testing ... please reply

Coming loud and clear !

joao



On Wed, 2009-04-22 at 13:21 -0400, Atul Chojar wrote:
> 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
>
>