Horton

Re: COPY FROM WHEN condition

Nasby, Jim <nasbyj@amazon.com>

View thread View on postgr.es
From: "Nasby, Jim" <nasbyj@amazon.com>
To: David Fetter <david@fetter.org>
Cc: Corey Huinker <corey.huinker@gmail.com>, "surafel3000@gmail.com" <surafel3000@gmail.com>, "cmt@burggraben.net" <cmt@burggraben.net>, "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Date: 2018-10-31T23:21:33Z
Lists: pgsql-hackers 
On Oct 11, 2018, at 10:35 AM, David Fetter <david@fetter.org> 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…)?

Commits

  1. Remove unused struct member, enforce multi_insert callback presence.

  2. Separate per-batch and per-tuple memory contexts in COPY

  3. Fix handling of volatile expressions in COPY FROM ... WHERE

  4. Allow COPY FROM to filter data using WHERE conditions

  5. Remove obsolete netbsd dynloader code