As long as the SQL standard is supported, support for the "ancient" syntax shouldn't be removed - at least not without a very long period of transition. Do you have any idea how many applications the removal of something simple like the cast operator :: will break? It's not difficult to write standard-compliant code in PostgeSQL - just feel free to use the standard. Nobody forces you to use the uncomliant syntax - but don't try to force thousands of people to rewrite tons of code just because you don't like the old syntax. Oracle has stuff like that, DB2 has too. Things evolve over time and unless you give code-maintainers ample time to fix their applications a sudden drop of old constructs will potentially just harm the project's popularity. I agree with you that the docs and examples should be amended to show standard constructs, just to encourage the adoption of standard compliant statements. Feel free to volunteer some time to make this happen - I'm confident everyone in the community will appreciate it. UC On Sunday 26 February 2006 00:36, Andrus Moor wrote: > It is difficult to write standard-compliant code in Postgres. > There are a lot of constructs which have SQL equivalents but are still used > widely, even in samples in docs! > > For example, there are suggestions using > > now()::CHAR!=foo > > while the correct way is > > CAST(CURRENT_DATE AS CHAR)<>foo > > now() function, :: and != operators should be removed from language. > > I like the Python logic: there is one way > Postgres uses C logic: there are multiple ways. > > Bruce seems to attempt start this process trying implement > escape_string_warning in postgresql.conf . However, this is only very minor > step. Please clean Postgres. > > Andrus. > > > > > ---------------------------(end of broadcast)--------------------------- > TIP 5: don't forget to increase your free space map settings -- Open Source Solutions 4U, LLC 1618 Kelly St Phone: +1 707 568 3056 Santa Rosa, CA 95401 Cell: +1 650 302 2405 United States Fax: +1 707 568 6416
