Re: ..horribly documented, inefficient, user-hostile, impossible to maintain interpreted language..

On Tue, Apr 5, 2011 at 1:04 PM, John R Pierce <pierce(at)hogranch(dot)com> wrote:
> On 04/05/11 9:40 AM, Merlin Moncure wrote:
>>
>> On Mon, Apr 4, 2011 at 2:20 PM, John R Pierce<pierce(at)hogranch(dot)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.

right -- it follows from my mantra to 'use built in functions when you
can' that string to array or regexp_split_to_array would probably work
for this case (maybe with some escaping, maybe not).

merlin