Re: ..horribly documented, inefficient, user-hostile, impossible to maintain interpreted language..
От | John R Pierce |
---|---|
Тема | Re: ..horribly documented, inefficient, user-hostile, impossible to maintain interpreted language.. |
Дата | |
Msg-id | 4D9B59CB.9000900@hogranch.com обсуждение исходный текст |
Ответ на | Re: ..horribly documented, inefficient, user-hostile, impossible to maintain interpreted language.. (Merlin Moncure <mmoncure@gmail.com>) |
Ответы |
Re: ..horribly documented, inefficient, user-hostile,
impossible to maintain interpreted language..
|
Список | 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 по дате отправления: