Re: [GENERAL] BUG #1830: Non-super-user must be able to copy from a

Sean,

Thanks for the psql suggestion. Certainly this is a possible robust
solution. The disadvantage could be that you need a new process for
each table. Or can you launch psql with multiple commands?

I am not looking for convenience mainly. I am interested in execution
speed, maintainability and portability.

Luckily I control the procedures for the server and I am now trusting
the application enough to give multiple instances of it postges
superuser connections.

With superuser connections, I can use COPY FROM FILE without
restrictions.

It should work unless something sinister in superuser jdbc connections
pops up. Any warnings?

I do this because I prefer to keep things clean, efficient and
streamlined. The application can run with different database engines.
The user decides which one to use. They may get documentation about
the security risks of running with superuser and the decision which
database to use is theirs.

Regards

Bernard

On Fri, 19 Aug 2005 01:10:46 -0700, you wrote:

>Yeah, I'm -vvv tonight.
>
>psql provides \COPY table from file
>
>how about
>String cmd = "psql -c '\COPY table from file' -U user -d database"
>Process p = Runtime.getRuntime( ).exec( cmd );
>yatta yatta yatta, blah blah blah
>
>naturally, if the database/server doesn't trust you, you'll have to jump
>some hoops to get the password to the server, but then, trust is really the
>issue, isn't it? And if you've been keeping an eye on the securityfocus
>lists, you'd know that it is all about the trust.
>
>What I keep hearing in this ongoing thread is the tradeoff between
>convenience and security.
>
>I want security, and you want convenience. If you own the server, you win.
>Buy a server, pay for the bandwidth, learn to administer a server, and all
>your problems disappear.
>
>Don't want to do that? Then you have to live by my rules, because I own the
>server, where your database lives.
>
>Once again, if you are the expert, solve the problem. If you are not, pay
>the expert to solve the problem. If the cost to fix the problem is higher
>than you are willing to pay, the problem is not that important. If the cost
>to fix the problem is more than you can afford --- bummer
>dude!!!!
>
>That is the way the world works. If you don't like it, look for a different
>world. If you are rich, and/or completely without morals, and prone to
>self-centered fantasy try the world of people who pretend to be Conservative
>Republicans in the USA. (This is not intended as a slam against people who
>are actually Republicans, or Conservatives --- unless they have failed to
>speak out against those who usurp their identity.)
>
>Sean
>
>
>
>----- Original Message -----
>From: "Bernard" <bht(at)actrix(dot)gen(dot)nz>
>To: "Greg Stark" <gsstark(at)mit(dot)edu>
>Cc: <pgsql-bugs(at)postgresql(dot)org>; <pgsql-general(at)postgresql(dot)org>
>Sent: Friday, August 19, 2005 12:21 AM
>Subject: Re: [GENERAL] [BUGS] BUG #1830: Non-super-user must be able to copy
>from a
>
>
>Greg,
>
>The desired COPY FILE functionality for a local non-superuser user
>would require a local file. That file is available locally.
>
>A suggested workaround COPY with STDIN would involve the TCP pipe.
>This does of course have the support for remote uploads.
>
>But I am not currently interested in remote data transfers.
>
>Regards
>
>Bernard
>
>On 19 Aug 2005 02:03:54 -0400, you wrote:
>
>>
>>Oliver Jowett <oliver(at)opencloud(dot)com> writes:
>>
>>> Bernard was also objecting to the overhead of pushing the data down a
>>> TCP pipe when it's already available locally, I think.. I didn't find
>>> any real difference there when I compared the two methods, though.
>>
>>What makes you think it's necessarily available locally?
>
>
>---------------------------(end of broadcast)---------------------------
>TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq
>
>
>
>
>---------------------------(end of broadcast)---------------------------
>TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match