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
