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 to questions > > Thanks! > Atul > > > > -----Original Message----- > From: pgsql-general-owner@xxxxxxxxxxxxxx [mailto:pgsql-general-owner@xxxxxxxxxxxxxx] On Behalf Of Joshua D. Drake > Sent: Wednesday, April 22, 2009 12:56 PM > To: Alvaro Herrera > Cc: S Arvind; pgsql-general@xxxxxxxxxxxxxx > Subject: Re: 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@xxxxxxxxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxx) > 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 > > -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
