Search Postgresql Archives

Re: Postgres 8.3 broke everything

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Yeah - I reckon that would do it ;)

And it did break just about every website on our systems!  Though the
change is understandable

Alex

On Thu, Feb 21, 2008 at 8:15 PM, Joshua D. Drake <jd@xxxxxxxxxxxxxxxxx> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>
>  On Thu, 21 Feb 2008 19:49:29 -0500
>
> "Alex Turner" <armtuk@xxxxxxxxx> wrote:
>
>
> > Yeah - I pressed tab to indent my code, and of course it tabbed to the
>  > next element on the page, which was the send button, then I hit a key,
>  > and it sent the message before I was ready.  I tested my hypothesis,
>  > but it was wrong.  I haven't quite figured it out yet.  Something to
>  > do with casting a char to an int I think, but I can't reproduce it
>
>  Based on this I bet you are being nailed by:
>
>
>  #
>
>  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.
>
>
>
>  - --
>
> The PostgreSQL Company since 1997: http://www.commandprompt.com/
>  PostgreSQL Community Conference: http://www.postgresqlconference.org/
>  Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
>  PostgreSQL SPI Liaison | SPI Director |  PostgreSQL political pundit
>
>  -----BEGIN PGP SIGNATURE-----
>  Version: GnuPG v1.4.6 (GNU/Linux)
>
>  iD8DBQFHviIeATb/zqfZUUQRAlyKAJ46gSgeP5dKS+CXba/lBhBL5dev1QCdEfGF
>  mZtO5L9dK2nAZZU4Cp6K+sA=
>  =HTW2
>  -----END PGP SIGNATURE-----
>

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not
       match


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux