Re: COPY FROM WHEN condition - Mailing list pgsql-hackers

From David Fetter
Subject Re: COPY FROM WHEN condition
Date
Msg-id 20181101004155.GI12677@fetter.org
Whole thread Raw
In response to Re: COPY FROM WHEN condition  ("Nasby, Jim" <nasbyj@amazon.com>)
Responses Re: COPY FROM WHEN condition  (Corey Huinker <corey.huinker@gmail.com>)
List pgsql-hackers
On Wed, Oct 31, 2018 at 11:21:33PM +0000, Nasby, Jim wrote:
> 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…)?

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 <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate


pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Is there way to detect uncommitted 'new table' in pg_class?
Next
From: Michael Paquier
Date:
Subject: Re: pg_promote not marked as parallel-restricted in pg_proc.dat