Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ctedI-0008Fd-B1 for pgsql-sql@arkaria.postgresql.org; Thu, 30 Mar 2017 18:17:16 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1ctedH-0006Bq-U3 for pgsql-sql@arkaria.postgresql.org; Thu, 30 Mar 2017 18:17:15 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ctedG-00068N-VS for pgsql-sql@postgresql.org; Thu, 30 Mar 2017 18:17:15 +0000 Received: from mail-it0-x236.google.com ([2607:f8b0:4001:c0b::236]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1ctedE-0002Of-OD for pgsql-sql@postgresql.org; Thu, 30 Mar 2017 18:17:13 +0000 Received: by mail-it0-x236.google.com with SMTP id 190so79732466itm.0 for ; Thu, 30 Mar 2017 11:17:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=nQrgVklKdzPSFTWYsxLK3r9cqm6WYUxBd72QmqEUBNo=; b=eOZz8QHX45rFuEpBYNoYWa94Lx9TJL0CE6/eK6XSksIOUhlP2rAO7btlnMcIHjcQQ2 9Naqg2LwdbN+5KWoGTZ17C0T5Kwa+ENHvh6zivpQJUPPm+Z895O13hqQmxQYVeP4TjP2 7TpJ1Mvuivr/y9BaR0aIaR+pEhfIfROySL28wmAQ/y81ALAlAUzzwvlp8U65QJ1tApa+ jx1T9wizpL4c9zqtItRE8AIS/h6qIluXjOhIfct3ArZ0gXB5D5TDzOOe3z5kt0VqsSx2 rg3/4YmqeR3F+17AwOGZrYNYrZbSK//lNLgmq04VU93qapz0xbjThhSmNOPDqijxol9k pByg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=nQrgVklKdzPSFTWYsxLK3r9cqm6WYUxBd72QmqEUBNo=; b=VQnwHrWkWhHAPZGxivin/UhtFRxHqMNEvopaLn7ItXoE+necXQrldc+TU285yfBBK7 xQuMdilNtlkE891LE9SUaMLr03flbT7JAmOizFWx9pMvtgzjy/9g8jygMQ3IK2F2pyNq 6qMClumE0B8lqJG1zV7sF0mjiigWcMvJ8RuvVYK/ugmjP6jq8JCv2/9yip+cahrHG2Eo f9cJBH5RevpS71GZ7iZS2MLMy7oFY6Nh/Wtalbu/p4LcWgzoirke36hONSf4VY0h0RIB M3iswMcoOHc0iGO6zy1r3U5zkYpQPz9NMQtGAmBlKJB2t8epfHG9ouOwMqGPUReDf9W0 odaA== X-Gm-Message-State: AFeK/H1v7rZvbFbiESibHKgqdgI8wKWl5gkK+xYcWGpOm7CvN8EzMHi71tFtzom/KES+sQ== X-Received: by 10.36.64.194 with SMTP id n185mr2060740ita.88.1490897831377; Thu, 30 Mar 2017 11:17:11 -0700 (PDT) Received: from [155.100.214.120] ([155.100.214.120]) by smtp.gmail.com with ESMTPSA id h71sm1770050ioe.9.2017.03.30.11.17.09 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Mar 2017 11:17:10 -0700 (PDT) Subject: Re: Query Advice To: pgsql-sql@postgresql.org References: From: Rob Sargent Message-ID: <931ab9ce-a6e0-1722-ef90-22b4c8ea94a0@gmail.com> Date: Thu, 30 Mar 2017 12:17:20 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------3DC6B0BAD5BF35130D3F0722" X-Pg-Spam-Score: -2.7 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-sql Precedence: bulk Sender: pgsql-sql-owner@postgresql.org This is a multi-part message in MIME format. --------------3DC6B0BAD5BF35130D3F0722 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 03/30/2017 12:13 PM, David G. Johnston wrote: > On Thu, Mar 30, 2017 at 11:03 AM, Gary Chambers >wrote: > > Is there a better way to get the company information along with > all of the > addresses in a single query? This works, but it requires the > additional > step of splitting the addresses by the the delimiter at the > application > layer. > > > ​To comment as to "better" without any knowledge of the "application > layer" doesn't make sense.​ > > I suggest you provide an example of what you'd like the output to look > like independent of any query concerns. > > ​David J. > If we assume the client layer is splitting by the pipe, why not just send the set of addresses and the client simply iterates over that, no hokey parsing involved. --------------3DC6B0BAD5BF35130D3F0722 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 03/30/2017 12:13 PM, David G. Johnston wrote:
On Thu, Mar 30, 2017 at 11:03 AM, Gary Chambers <gwchamb@gwcmail.com> wrote:
Is there a better way to get the company information along with all of the
addresses in a single query?  This works, but it requires the additional
step of splitting the addresses by the the delimiter at the application
layer.

​To comment as to "better" without any knowledge of the "application layer" doesn't make sense.​

I suggest you provide an example of what you'd like the output to look like independent of any query concerns.

​David J.

If we assume the client layer is splitting by the pipe, why not just send the set of addresses and the client simply iterates over that, no hokey parsing involved.
--------------3DC6B0BAD5BF35130D3F0722--