Re: language interface in postgresql - Mailing list pgsql-general

From David Fetter
Subject Re: language interface in postgresql
Date
Msg-id 20070816054301.GC603@fetter.org
Whole thread Raw
In response to Re: language interface in postgresql  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: language interface in postgresql  (Ron Mayer <rm_pg@cheapcomplexdevices.com>)
List pgsql-general
On Wed, Aug 15, 2007 at 01:10:15AM -0400, Tom Lane wrote:
> "Scott Marlowe" <scott.marlowe@gmail.com> writes:
> > On 8/14/07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> ...  I think we probably are unique in being so aggressively
> >> agnostic about what the function language is.  That's not
> >> necessarily all good, as it's driven us to invent curiosities
> >> like dollar-quoting to avoid having to mesh lexical details of
> >> the function language and the outer SQL language.
>
> > Well, I for one LOVE $$ quoting in the newer versions of pgsql.
> > Having statements with ''''''''value'''''''' in the, was downright
> > annoying in 7.4...
>
> You bet, but the reason why it was like that was we insisted on the
> function body being a string literal in the eyes of the outer CREATE
> FUNCTION command.  Anytime the function's language had the same
> ideas about string quoting and escaping rules as the outer SQL
> language does, you were in for some recursively bad experiences.
>
> Dollar-quoting is a cute technical solution to that, but you can't
> deny that it's simpler if you just restrict the function language to
> be SQL-ish so that CREATE FUNCTION can parse it without any
> interesting quoting rules.  So sayeth Oracle and the SQL standards
> committee, anyway.

I think the aforementioned entities got it wrong where we got it right :)

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
phone: +1 415 235 3778        AIM: dfetter666
                              Skype: davidfetter

Remember to vote!
Consider donating to PostgreSQL: http://www.postgresql.org/about/donate

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: SELECT ... FOR UPDATE performance costs? alternatives?
Next
From: "Phoenix Kiula"
Date:
Subject: Re: Fastest way to import only ONE column into a table? (COPY doesn't work)