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 re
This is silly.
The bug being reported is that a non-super-user can't copy from a server
side file with JDBC.
There are a jillion (no, really, a jillion) other ways to accomplish this,
because as is the Perl motto, there is more than one way to do it.
If this is really so important, Bernard
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
som
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
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
Greg Stark wrote:
Oliver Jowett <[EMAIL PROTECTED]> 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'
Sean,
Very diplomatic way to get the message across without offending anyone
except the bastards.
Capatalism is good for development. But it has to be kept in check as
to not destroy the basis on which it once grew and provided fair
chances for anyone to participate. Who is keeping it in check to
Bernard wrote:
Certainly supporting COPY via STDIN within the java code seems preferable.
Why do you say that? That option does not exist because the Postgresql
JDBC driver does not support it.
If you raise this on pgsql-jdbc (so far, I haven't seen anything on that
list from you at all..)
* Stephan Szabo ([EMAIL PROTECTED]) wrote:
>
> On Fri, 19 Aug 2005, Bernard wrote:
>
> > My suggestions for improving the COPY command so it can be used by
> > non-superuser users would be as follows:
>
> If you want to do this without switching to a different UNIX user, can't
> you already writ
Oliver Jowett <[EMAIL PROTECTED]> 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 ava
The following bug has been logged online:
Bug reference: 1835
Logged by: Qayed
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.4
Operating system: Win XP
Description:pg_trigger_tgrelid_tgname_index
Details:
While trying to connect to postgresql database i m g
Bernard schrieb:
Andrew
On Fri, 19 Aug 2005 04:17:16 -, you wrote:
In the majority of bulk load cases, the input exists as a file already
But not necessarily on the server.
True. But I am concerned with the server, and there I want that things
are handled on the server, not on the cl
Hi,
I am having problems importing sql files containing WAVE DASH or MINUS
character :
WARNING: ignoring unconvertible UTF-8 character 0xe3809c
WARNING: ignoring unconvertible UTF-8 character 0xe28892
The data contains japanese characters and is imported correctly apart
from these two. It seem
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> Tom Lane once mentioned that "Valgrind is fairly useless for debugging
> postgres," but has anybody tried it for this problem? I tried using
> the FreeBSD port but it's having trouble (first I had to hack in
> support for a system call, now it's t
"Qayed" <[EMAIL PROTECTED]> writes:
> While trying to connect to postgresql database i m gettting this error,
> FATAL:could not open relation "pg_trigger_tgrelid_tgname_index":Permission
> denied.
Apparently the database server is unable to open its own files due to
filesystem permission checks.
Martijn van Oosterhout writes:
> On Fri, Aug 19, 2005 at 09:15:52AM -0400, Stephen Frost wrote:
>> Personally, I do like the idea of a user-level 'copy server-side files'
>> permission that could be granted to reduce the need for things to run as
>> superuser.
> There is one important point thoug
On Fri, Aug 19, 2005 at 01:56:39PM -, Greg Sabino Mullane wrote:
> > Tom Lane once mentioned that "Valgrind is fairly useless for debugging
> > postgres," but has anybody tried it for this problem?
>
> I've got valgrind working, but not sure exactly how to use it to debug
> this problem. What'
On Fri, 19 Aug 2005, Bernard wrote:
> But we can take this one step further so that we don't even need to
> trust ourselves:
>
> The logical next step is that for a non-postgresql-superuser user,
> COPY FROM files have to be world-readable and COPY TO files and
> directories have to be world-writa
PostgreSQL version: 8.0.3
Operating system: Linux (SuSE 9.1)
I have a UNICODE database, trying to compare two unicode strings (Ethiopic
characters). Client encoding is also UNICODE:
===
testdb=> select 'በድሩ ሁሴን'='ሰይፉ ከበደ';
?column?
--
t
(
=?UTF-8?B?SsO2cmcgSGF1c3RlaW4=?= <[EMAIL PROTECTED]> writes:
> I have a UNICODE database, trying to compare two unicode strings (Ethiopic
> characters). Client encoding is also UNICODE:
> ===
> testdb=> select 'á áµá© áá´á'='á°áá á¨á á
On Fri, Aug 19, 2005 at 08:03:39AM -0700, Stephan Szabo wrote:
> On Fri, 19 Aug 2005, Bernard wrote:
>
> > But we can take this one step further so that we don't even need to
> > trust ourselves:
> >
> > The logical next step is that for a non-postgresql-superuser user,
> > COPY FROM files have to
On Wed, Aug 17, 2005 at 11:37:58PM -0600, Michael Fuhr wrote:
> With HEAD on Solaris 9/sparc I don't have to reconnect before the
> SELECT to get the error (I tested both ways, with and without a
> reconnect, and it made no difference).
> I get the same results on FreeBSD 4.11-STABLE/x86 but I hav
On Fri, Aug 19, 2005 at 09:03:48PM -0600, Michael Fuhr wrote:
> Here's a summary of what I see on both systems:
I mentioned this before but forgot to include it in the summary:
* If I execute "SELECT foo()" before I execute "SELECT bar()" then
I don't get the error.
Here's my current test case
I'm wondering if this is Perl version dependent. I've tried with
Fedora Core 3:
This is perl, v5.8.5 built for i386-linux-thread-multi
Darwin 10.4.2:
This is perl, v5.8.6 built for darwin-thread-multi-2level
with no failures observed... what are you guys using?
regards,
[ eyeing current plperl code... ]
Would anyone like to explain what ::_plperl_to_pg_array is for, and
why it's only created by loose_embedding[] and not strict_embedding[]?
Not that this looks to have any immediate impact on the problem at
hand, but it still looks a tad broken.
On Sat, Aug 20, 2005 at 12:03:46AM -0400, Tom Lane wrote:
> I'm wondering if this is Perl version dependent. I've tried with
>
> Fedora Core 3:
> This is perl, v5.8.5 built for i386-linux-thread-multi
> Darwin 10.4.2:
> This is perl, v5.8.6 built for darwin-thread-multi-2level
>
> with no failur
Michael Fuhr <[EMAIL PROTECTED]> writes:
> I see that both of your Perl version strings have "thread-multi"
> whereas neither of mine do. I don't know if that's relevant, but
> it's something different about the Perl builds.
Hm. I also have a 5.8.7-no-threads Perl build on HPPA. I hadn't
tried
On Sat, Aug 20, 2005 at 12:22:05AM -0400, Tom Lane wrote:
> Would anyone like to explain what ::_plperl_to_pg_array is for, and
> why it's only created by loose_embedding[] and not strict_embedding[]?
It looks like plperl_convert_to_pg_array() calls that Perl function
to convert a Perl list refere
Michael Fuhr <[EMAIL PROTECTED]> writes:
> But this example crashes the backend if plperl.use_strict is enabled :-(
I suspect the croak() in plperl_convert_to_pg_array (the C function)
ought to be an ereport(). It looks like that is not called from inside
the Perl environment, and so croak is pro
On Sat, Aug 20, 2005 at 01:14:02AM -0400, Tom Lane wrote:
> One thing I was kind of wondering about (this will betray the fact
> that I haven't really studied Perl since it was Perl 4) is what are
> the namespace issues for ::mksafefunc? In particular, could the
> inner invocation of foo() be exec
On Fri, Aug 19, 2005 at 11:16:25PM -0600, Michael Fuhr wrote:
> But this example crashes the backend if plperl.use_strict is enabled :-(
The PL/Perl regression tests also fail if use_strict is enabled,
mostly due to not using "my" in a few places. I'll work on a patch.
--
Michael Fuhr
Michael Fuhr <[EMAIL PROTECTED]> writes:
> You might be on to something there. I just changed line 683 in
> plperl.c to the following:
> count = perl_call_pv((trusted ? "::mksafefunc" : "::mkunsafefunc"),
> My test cases now succeed where they had been failing. But if
> that's the problem,
On Sat, Aug 20, 2005 at 01:59:59AM -0400, Tom Lane wrote:
> Michael Fuhr <[EMAIL PROTECTED]> writes:
> > My test cases now succeed where they had been failing. But if
> > that's the problem, why are your systems behaving differently?
>
> Damifino. I have just found out that the HPPA 5.8.7 no thr
33 matches
Mail list logo
