On Tue, Apr 5, 2011 at 1:04 PM, John R Pierce <pierce@xxxxxxxxxxxx> wrote: > On 04/05/11 9:40 AM, Merlin Moncure wrote: >> >> On Mon, Apr 4, 2011 at 2:20 PM, John R Pierce<pierce@xxxxxxxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
