Re: ..horribly documented, inefficient, user-hostile, impossible to maintain interpreted language.. - Mailing list pgsql-general

From Merlin Moncure
Subject Re: ..horribly documented, inefficient, user-hostile, impossible to maintain interpreted language..
Date
Msg-id BANLkTikufX5M0yfqZKwvcT+9+os1_dbwAQ@mail.gmail.com
Whole thread Raw
In response to Re: ..horribly documented, inefficient, user-hostile, impossible to maintain interpreted language..  (John R Pierce <pierce@hogranch.com>)
Responses Re: ..horribly documented, inefficient, user-hostile, impossible to maintain interpreted language..
List pgsql-general
On Mon, Apr 4, 2011 at 2:20 PM, John R Pierce <pierce@hogranch.com> wrote:
> On 04/04/11 12:07 PM, Martin Gainty wrote:
>>
>> ..horribly documented, inefficient, user-hostile, impossible to maintain
>> interpreted language..
>> to whom might you be alluding to
>
> I only used a few of those adjectives, and prefixed them by hypothetical.
> to be honest, I would expect most languages commonly used in web service
> environments to be more efficient at string processing than pl/pgsql, and I
> really can't think of a counterexample off the top of my head.

most language *are* more efficient at string processing but that's not
the whole story, since to get at that benefit you typically have to:

1. application makes query to get the data
2. database searches for data, converts it to wire format and sends it
through protocol to libpq
3. libpq wrapper converts it to language native string (unless you are in C)
4. language string processing takes place
5. data is re-stacked into queries and sent back to the database over
wire format via protocol
6. database writes it out

Now, if your data is not meant for consumption by the database then
the case for application side coding is stronger.  But if you are just
manhandling data only to send it right back the database you should
think twice about introducing all those steps to access the benefits.
Not to mention, by introducing a client side procedural language you
are introducing a whole new set of data types, conditions, constraint
checking etc.  Procedural languages are also defect factories (this
includes pl/pgsql if written in more procedural fashion, so you should
keep it to sql, or at least in relational style if you can).

pl/pgsql is perfectly fine for string processing as long as your
problem is such that you can avoid heavy iteration (string
concatenation in a loop is especially problematic, but work around
that using arrays is trivial and effective) and manage the strings
relationally and with the built in functions.

The better you are with sql, the less iteration you tend to need.  The
server backend string api is fairly rich and can get you through most
light to moderate string processing tasks.

merlin

pgsql-general by date:

Previous
From: Zeev Ben-Sender
Date:
Subject: Is index rebuilt upon updating table with the same values as already existing in the table?
Next
From: Chris Oldfield
Date:
Subject: Problem with multiple action rule on modifiable view