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 client.
>
>> The use
Tom Lane wrote:
> Oliver Jowett <[EMAIL PROTECTED]> writes:
>
>>It sounds like what you really want is the ability to grant something
>>like FILE access without granting all superuser rights? Sounds like a
>>feature request, not a bug, to me :-)
>
>
> AFAICT, the complaint really boils down to t
Tom Lane wrote:
> What is the story on JDBC COPY support, anyway? I'm aware that there's
> an unofficial patch for that, but I'm not clear about why it's not made
> it into the accepted version.
I didn't like the whole "here is an undifferentiated stream of data"
approach -- there were some JDBC
Oliver Jowett <[EMAIL PROTECTED]> writes:
> It sounds like what you really want is the ability to grant something
> like FILE access without granting all superuser rights? Sounds like a
> feature request, not a bug, to me :-)
AFAICT, the complaint really boils down to there not being any support
f
[ A bit off topic, but... ]
Oliver Jowett <[EMAIL PROTECTED]> writes:
> And please fix your anti-spam system so it doesn't send me a "you must
> jump through these hoops to send me email" message every time please!
It's standard policy on the PG lists that we boot subscribers who
auto-reply to li
On 2005-08-19, Bernard <[EMAIL PROTECTED]> wrote:
> Oliver and interested list members:
>
> In the majority of bulk load cases, the input exists as a file already
But not necessarily on the server.
> The use of psql in our case requires the launching of an external
> process from within the runni
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 write a small SECURITY DEFINER function as a superuser that
doe
Bernard wrote:
> 2) Split up security risk calculations between the two directions "TO"
> and "FROM" and relax security. Look at MySQL for clues. The
> application developer can manage security on file system permission
> level.
I looked at MySQL's docs briefly and its behaviour seems almost the
On Fri, Aug 19, 2005 at 10:16:29AM +1200, Bernard wrote:
> Bruno and interested list members
>
> I want to follow what is suggested here. How are STDIN and STDOUT
> addressed when using the JDBC driver?
>
> Or in other words where can I write or receive megabytes of data?
I don't know how JDBC d
"Oliver Jowett" <[EMAIL PROTECTED]>
wrote:[EMAIL PROTECTED]
> Bernard wrote:
>
>> The majority of JDBC users trying to bulk load tables would not want
>> to send the data through their connection. This connection is designed
>> to send commands and to transfer only as much data as necessary and a
Oliver and interested list members:
In the majority of bulk load cases, the input exists as a file already
and cannot be had without reading from that file. So the writing of
the file does not count as an additional processing overhead.
The use of psql in our case requires the launching of an ext
Bernard wrote:
> Oliver and interested list members:
[...]
And please fix your anti-spam system so it doesn't send me a "you must
jump through these hoops to send me email" message every time please!
(usual cc: to poster removed for that reason)
-O
---(end of broadcast)
Bernard wrote:
> This difference of performance is the main reason for the COPY
> command, and this is also the reason why bulk loading through the JDBC
> interface will never match the performance of the COPY fith files
> command.
In some admittedly unscientific tests I see less than 10% differe
On Thu, Aug 18, 2005 at 02:52:02PM -, Greg Sabino Mullane wrote:
> Tom Lane asked:
> > I could not duplicate this in either 8.0 or HEAD branches. It looks
> > a bit like an old bug that we had in plperl, though. Are you sure your
> > plperl.so is up to date?
>
> Looks like Michael is already
Oliver and interested list members:
I was referring to the majority of users wanting to "bulk" load tables
not to the majority of all or whatever users who may or may not know
or care about the difference in performance between INSERT and COPY.
This difference of performance is the main reason fo
Bernard wrote:
> The majority of JDBC users trying to bulk load tables would not want
> to send the data through their connection. This connection is designed
> to send commands and to transfer only as much data as necessary and as
> little as possible.
I don't understand why this is true at all
Oliver and interested list members:
Thanks for the related information.
The majority of JDBC users trying to bulk load tables would not want
to send the data through their connection. This connection is designed
to send commands and to transfer only as much data as necessary and as
little as poss
Bernard wrote:
> I want to follow what is suggested here. How are STDIN and STDOUT
> addressed when using the JDBC driver?
The current JDBC driver doesn't support this mode of COPY.
There was some work done in the past to support this but it never got to
the point of making it into the official
The following bug has been logged online:
Bug reference: 1834
Logged by: Bernard
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.03
Operating system: Linux RedHat 9
Description:Non-super-user must be able to copy from a file through
JDBC
Details:
On the attem
Bruno and interested list members
I want to follow what is suggested here. How are STDIN and STDOUT
addressed when using the JDBC driver?
Or in other words where can I write or receive megabytes of data?
I would not want to append this to the String of a SQL Statement in
Java because that is a S
"Bohdan Linda" <[EMAIL PROTECTED]> writes:
> Description:Can't create function in plpgsql which has more than 10
> parameters
Your example works fine for me. Maybe something broken about your local
copy of Postgres?
regards, tom lane
---(e
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Lane asked:
> I could not duplicate this in either 8.0 or HEAD branches. It looks
> a bit like an old bug that we had in plperl, though. Are you sure your
> plperl.so is up to date?
Looks like Michael is already far along, but yes, my plperl.s
Redirecting this to pgsql-bugs where it belongs.
Robert Treat
On Wed, 2005-08-17 at 01:29, Lee Hyun soon wrote:
> From: "Lee Hyun soon" <[EMAIL PROTECTED]>
> To: pgsql-bugs@postgresql.org
> Date: Wed, 17 Aug 2005 05:36:23 +0100 (BST)
> Subject: BUG #1826: pgsql odbc & ADO.NET
>
> The following
The following bug has been logged online:
Bug reference: 1832
Logged by: Bohdan Linda
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.3.4
Operating system: Solaris
Description:Can't create function in plpgsql which has more than 10
parameters
Details:
I have
24 matches
Mail list logo
