Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1gI13j-0002IJ-RT for pgsql-hackers@arkaria.postgresql.org; Thu, 01 Nov 2018 00:42:03 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gI13h-0003S8-Hj for pgsql-hackers@arkaria.postgresql.org; Thu, 01 Nov 2018 00:42:01 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1gI13h-0003S1-9y for pgsql-hackers@lists.postgresql.org; Thu, 01 Nov 2018 00:42:01 +0000 Received: from xvm-110-146.dc2.ghst.net ([46.226.110.146] helo=fetter.org) by magus.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gI13e-00081Y-5F for pgsql-hackers@lists.postgresql.org; Thu, 01 Nov 2018 00:42:00 +0000 Received: by fetter.org (Postfix, from userid 1001) id 0917741D22; Thu, 1 Nov 2018 01:41:56 +0100 (CET) Date: Thu, 1 Nov 2018 01:41:55 +0100 From: David Fetter To: "Nasby, Jim" Cc: Corey Huinker , "surafel3000@gmail.com" , "cmt@burggraben.net" , "pgsql-hackers@lists.postgresql.org" Subject: Re: COPY FROM WHEN condition Message-ID: <20181101004155.GI12677@fetter.org> References: <20181011085925.5zopu7jvxzs5c4xq@squirrel.exwg.net> <20181011153505.GL6157@fetter.org> <5E61B32E-61CB-4EBB-BC8E-BE37DC6E79AB@amazon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5E61B32E-61CB-4EBB-BC8E-BE37DC6E79AB@amazon.com> User-Agent: Mutt/1.5.24 (2015-08-30) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Wed, Oct 31, 2018 at 11:21:33PM +0000, Nasby, Jim wrote: > On Oct 11, 2018, at 10:35 AM, David Fetter wrote: > > > >> It didn't get far, but you may want to take a look at a rejected patch for > >> copy_srf() (set returning function) > >> https://www.postgresql.org/message-id/CADkLM%3DdoeiWQX4AGtDNG4PsWfSXz3ai7kY%3DPZm3sUhsUeev9Bg%40mail.gmail.com > >> https://commitfest.postgresql.org/12/869/ > >> > >> Having a set returning function gives you the full expressiveness of SQL, > >> at the cost of an extra materialization step. > > > > I wonder whether something JIT-like could elide this. A very > > interesting subset of such WHEN clauses could be pretty > > straight-forward to implement in a pretty efficient way. > > Are you thinking something like having a COPY command that provides > results in such a way that they could be referenced in a FROM clause > (perhaps a COPY that defines a cursor…)? That would also be nice, but what I was thinking of was that some highly restricted subset of cases of SQL in general could lend themselves to levels of optimization that would be impractical in other contexts. Best, David. -- David Fetter http://fetter.org/ Phone: +1 415 235 3778 Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate