On Sun, Oct 25, 2009 at 8:49 PM, Adrian Klaver
<aklaver@comcast.net> wrote:
On Sunday 25 October 2009 9:17:04 am Timothy Madden wrote:
> On Sat, Oct 24, 2009 at 5:41 PM, Tom Lane <
tgl@sss.pgh.pa.us> wrote:
> > Timothy Madden <
terminatorul@gmail.com> writes:
> > > Can the string literal syntax for the function body in a CREATE
> > > FUNCTION statement please,
> > > please be dropped ?
> >
> > No. Since the function's language might be anything, there's no way to
> > identify the end of the function body otherwise.
>
> There is a SQL standard for this, and other DBMS look like they found a way
> ...
>
> How come it can not be done ?
literal syntax goes away functions created for Postgres make use of Postgres
specific syntax and extensions. So there is going to be a translation step
involved irregardless of the string issue. So just out of curiosty what problem
does the string syntax cause?
Just like when I write C++ applications I use standards-conforming C++, when I write SQL
applications I would like to use standard-conforming SQL.
I would normally write standard-conforming C++ code even when porting is not actually a
stated requirement in my project, just because portable code is the right code. Should my
project need some specific function or library, at least the platform-specific code should
be grouped in a separate module/directory. I think there are many, many other developers
that agree with me in this regard. After all PostgreSql is open-source and portable.
For SQL, at the current conformance and compatibility level among DBMS providers in use
today, one could rightly say there is no such thing as conforming or portable SQL application
in real-world. However my intent is still the same, to write conforming (SQL) code. Or at least
try, as much as it is possible. One day the world of DBMS providers will eventually get better
in this regard.
So I would expect any open source, state-of-the-art DBMS system to have
standards-compliance as one of its goals (if not already one of its features). I am
happy to say PosgreSQL rates pretty well, if not the best, when compared with
other (commercial and non-commercial) DBMSs by standards-conformance.
Maybe this is also why I have these high expectations ...
Thank you,
Timothy Madden