Re: Can the string literal syntax for function definitions please be dropped ?

On Sun, Oct 25, 2009 at 2:43 PM, Timothy Madden <terminatorul(at)gmail(dot)com> wrote:
>
>
> On Sun, Oct 25, 2009 at 8:49 PM, Adrian Klaver <aklaver(at)comcast(dot)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(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> > > Timothy Madden <terminatorul(at)gmail(dot)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 ?
>>
>> I am trying to determine the problem you are trying to solve. Even if the
>> string
>> 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.

But as soon as the rubber hits the road, not two C or C++ compilers
are really 100% compatible as are no two SQL implementations.

Simply wanting things to be the same across all DBs seems kind of
naive as a reason to change pg's behaviour.

> 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.

So your argument is more philosophical than logical? Not that
philosophy doesn't have its place, but a logical reason would carry
far more weight here.

> 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.

I haven't seen them on this list really. I'm entirely against it, but
if it breaks stuff I've already got that works and works well then I
have no real need for it, especially if it's ONLY for the purpose of
being SQL standard compliant and not for meeting some real world need.

> 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.

A large part of the reason for this is that parts of the SQL spec are
just plain strange and weird and implementing them gains us little or
nothing. The SQL spec is far more open to interpretation than the C
or C++ specs, and has changed a LOT more in the last ten years than
those as well. It's a moving target in many ways, and while many
parts of it make perfect sense to be implemented as written, a
noticeable minority of it doesn't warrant implementation / changes to
comply.

> 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.

They've been doing that very thing for the last 20 or so years. But I
think that differences in implementation and philosophy will always
result in some divergence of SQL interface.