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
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-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

Browse pgsql-hackers by date

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

Browse pgsql-patches by date

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