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

From Scott Marlowe
Subject Re: language interface in postgresql
Date
Msg-id dcc563d10708142150l6b7bc5fbja3f0e0f4fc0db169@mail.gmail.com
Whole thread Raw
In response to Re: language interface in postgresql  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: language interface in postgresql  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
On 8/14/07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Jasbinder Singh Bali" <jsbali@gmail.com> writes:
> > Let me fine tune my question here. What I mean to say is the way we can
> > write stored procedures in C, perl etc in Postgres specifying the language
> > parameter at the end of stored procedure, compared to that, in SQL Server
> > 2000 I've seen SP writing in pure SQL only.
>
> Ah.  I thought you were talking about client interface libraries in
> different languages, which are surely a dime a dozen.  As far as
> server-side functions go, we might be unique in offering so many
> languages to work in.  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...

I think the real issue with all the pl languages is the variations in
quality of implementations out there.  And some don't always make it
to the next release, or if they do they lag behind.  I believe plsh
was quite late to show up for 8.0 back in the day...  If you're
relying on a particular pl{lang} you kinda want to check to see if
it's still working on the latest pg version before upgrading.

pgsql-general by date:

Previous
From: "Scott Marlowe"
Date:
Subject: Re: Transactional DDL
Next
From: Tom Lane
Date:
Subject: Re: Transactional DDL