cc'ing the list, haven't seen it show up there....
And yeah, I'm using Outlook Express and the quoting is crappy. So sue me....
I never saw your request rejected, though it did rank low on priority -- in
my book at least. The problem has been discussed at length, and there are
multiple ways to solve your problem without making any changes to postgres.
Because there are so many ways to solve your problem, your request amounts
to a feature, not a bug, and a very low ranking feature at that. Just
because other similar systems do something, does not mean that anyone else
should. If you like the way they do it better, go with them. Microsoft
allowed Outlook to set up volunteer administrators if they sent a properly
crafted email -- some people like that sort of thing.
While I really appreciate your attempts to motivate the postgres team to
action through peer pressure (mysql and all the other databases kiss on the
first date) -- as I said, if you can't personally fix the problem, and you
won't/can't pay someone else to fix the problem, then you have to hope that
the problem bugs someone who can pay to fix the problem, or that someone who
can fix the problem feels the itch, and can scratch it. That may or may not
make you happy, but it is the reality. Again, there are many other ways to
solve this problem (uploading bulk table date) -- I am going to make a
wild-ass guess that the phpPgAdmin team have had to address this issue
(http://phppgadmin.org/) and have come to some compromise.
Dump the vinegar, try the honey.
Sean
----- Original Message -----
From: "Bernard" <bht@xxxxxxxxxxxxx>
To: "Sean Utt" <sean@xxxxxxxxxxxx>
Sent: Friday, August 19, 2005 1:52 AM
Subject: Re: [BUGS] BUG #1830: Non-super-user must be able to copy from a
file
Sean,
I am glad that our discussion has come this far, because at the start
of it, my request was rejected as not being relevant and I was looking
a bit depressed.
The options for fast bulk loads from within a Java server programs as
non-superuser user are clearly limited and inefficient.
I still had trouble explaining the issue and after some time, it has
become obvious that the STDIN option suggested for COPY is not
available in the JDBC driver.
Oliver asked to suggest a solution that does not open any security
holes.
A simple solution has been suggested that works without changes to the
JDBC driver. I repeat it here:
For a non-postgresql-superuser user, COPY FROM files have to be
world-readable and COPY TO files and directories have to be
world-writable. The server checks the file attributes and grants copy
permission depending on them. Obviously any Postrgres system files
must not be world-readable and world-writable.
I am not suggesting to enhance the JDBC driver to support COPY with
STDIN, because my architecture doesn't require it and it is clearly
going to be slower due to driver/comms overhead.
I appreciate your comments regarding funding of developers. I hope I
will be able to provide a share in the future but currently I am not
in the position to do so.
Regards
Bernard
On Fri, 19 Aug 2005 00:46:29 -0700, you wrote:
...
Bottom line:
If this is really important to you, either fix the problem, or provide
someone else with incentive to fix the problem.
In this case, attempting to appeal to/tear down the ego of the developers
is
not working, so you will have to resort to more concrete methods, i.e.
money. Nice effort though. No matter how much our pride is involved in
this,
nothing greases the wheels like cash.
Sean
---------------------------(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
