Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Performance testing of COPY (SELECT)

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Zoltan Boszormenyi <zboszor(at)dunaweb(dot)hu>, Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-patches(at)postgresql(dot)org
Subject: Re: [HACKERS] Performance testing of COPY (SELECT)
Date: 2006-08-28 22:47:31
Message-ID: 200608282247.k7SMlVj16231@momjian.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Tom Lane wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> > Zoltan Boszormenyi wrote:
> >> My v8 had the syntax support for
> >>	COPY (SELECT ...) (col1, col2, ...) TO
> >> and it was actually working. In your v9
> >> you rewrote the syntax parsing so that
> >> feature was lost in translation.
> 
> > Interesting.  I didn't realize this was possible -- obviously I didn't
> > test it (did you have a test for it in the regression tests?  I may have
> > missed it).  In fact, I deliberately removed the column list from the
> > grammar, because it can certainly be controlled inside the SELECT, so I
> > thought there was no reason the support controlling it in the COPY
> > column list.
> 
> I would vote against allowing a column list here, because it's useless
> and it strikes me as likely to result in strange syntax error messages
> if the user makes any little mistake.  What worries me is that the
> above looks way too nearly like a function call, which means that for
> instance if you omit a right paren somewhere in the SELECT part, you're
> likely to get a syntax error that points far to the right of the actual
> mistake.  The parser could also mistake the column list for a table-alias
> column list.
> 
> Specifying a column list with a view name is useful, of course, but
> what is the point when you are writing out a SELECT anyway?

If you don't support COPY view TO, at least return an error messsage
that suggests using COPY (SELECT * FROM view).  And if you support COPY
VIEW, you are going to have to support a column list for that.  Is that
additional complexity in COPY?  If so, it might be a reason to just
throw an error on views and do use COPY SELECT.

Seeing that COPY VIEW only supports TO, not FROM, and COPY SELECT
support only TO, not FROM, it seems logical for COPY to just support
relations, and COPY SELECT to be used for views, if we can throw an
error on COPY VIEW to tell people to use COPY SELECT.

-- 
  Bruce Momjian   bruce(at)momjian(dot)us
  EnterpriseDB    http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

In response to

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2006-08-28 22:54:13
Subject: Re: updated patch for selecting large results sets
Previous:From: Matthew T. O'ConnorDate: 2006-08-28 22:39:35
Subject: Re: autovacuum causing numerous regression-test failures

pgsql-patches by date

Next:From: Bruce MomjianDate: 2006-08-28 22:54:13
Subject: Re: updated patch for selecting large results sets
Previous:From: Chris MairDate: 2006-08-28 22:38:49
Subject: Re: [PATCHES] updated patch for selecting large results

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group