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

From John R Pierce
Subject Re: ..horribly documented, inefficient, user-hostile, impossible to maintain interpreted language..
Date
Msg-id 4D9B59CB.9000900@hogranch.com
Whole thread Raw
In response to Re: ..horribly documented, inefficient, user-hostile, impossible to maintain interpreted language..  (Merlin Moncure <mmoncure@gmail.com>)
Responses Re: ..horribly documented, inefficient, user-hostile, impossible to maintain interpreted language..
List pgsql-general
On 04/05/11 9:40 AM, Merlin Moncure wrote:
> On Mon, Apr 4, 2011 at 2:20 PM, John R Pierce<pierce@hogranch.com>  wrote:
>> 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

in the OP's case, he was asking about strings he was inserting into
postgres, currently he was inserting them as a single long field, but he
wanted to break them up into multiple fields.  So, he could send the
long string to a pgsql function that did the dicing up, or he could dice
up the string first then send the pieces to fields of a database.    I
was expressing the opinion that its highly likely the 2nd solution would
work better, and I guess my bit of misplaced humor clouded that message.



pgsql-general by date:

Previous
From: "C. Bensend"
Date:
Subject: Re: Plpgsql function to compute "every other Friday"
Next
From: Merlin Moncure
Date:
Subject: Re: ..horribly documented, inefficient, user-hostile, impossible to maintain interpreted language..