From: | Rod Taylor <pg(at)rbt(dot)ca> |
---|---|
To: | tshipley(at)deru(dot)com |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: feature proposal ... |
Date: | 2005-09-21 22:32:23 |
Message-ID: | 1127341943.94955.40.camel@home |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 2005-09-21 at 15:25 -0700, Trent Shipley wrote:
> On Wednesday 2005-09-21 07:01, Hans-Jürgen Schönig wrote:
> > Rod Taylor wrote:
> > >>the problem is: COPY can write data returned by a SELECT statement to a
> > >>file. our idea is to implement precisely that.
> > >>
> > >>example:
> > >>
> > >>COPY TO file_name USING some_select_statement;
> > >
> > > I have run into plenty of cases where I wanted to dump part of a
> > > structure and this could be used for that, but I've always found that
> > > temporary tables were sufficient and equally SQL scriptable
> > >
> > > CREATE TEMP TABLE tab AS SELECT ...; COPY tab TO file_name;
> >
> > Hi Rod,
> >
> > TEMP TABLE are not suitable for my case. Using a temp table would
> > essentially mean that we had to store the data 3 times: Original data,
> > temp table + dump. Temp tables are only fine for small amounts of data
> > but we are talking about too much data here (my smallest export will
> > contain 15.000.000 records).
>
> Wouldn't you also need a CREATE TEMP TABLE privilege but the
> COPY TO file USING select_statement
> would only need select. (In other words using a temp table would not seem to
> be as secure nor as general as the requested feature.)
Writing a file on the server requires significant privilege, including
access to the server itself so you can retrieve the results.
--
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2005-09-21 23:55:38 | Re: feature proposal ... |
Previous Message | Trent Shipley | 2005-09-21 22:25:47 | Re: feature proposal ... |