On Mon, 17 Dec 2007, Merlin Moncure wrote:
the table is pg_proc. you have to revoke select rights from public
and the user of interest. be aware this will make it very difficult
for that user to do certain things in psql and (especially) pgadmin.
it works.
a better solution to this problem
Hi All,
Thanks for all the help here. Sorry for the late update but we've found our
problem and fixed it already. Prior to looking at the translated code more
intently, I wanted to make sure that our environmental settings were acceptable
and the various emails from members have confirmed t
Craig James wrote:
Don't confuse thread-friendly with a threaded implemetation of
Postgres itself. These are two separate questions. Thread-friendly
involves compile/link options that don't affect the Postgres source
code at all.
Indeed. I'm specifically not suggesting that Postgres should o
Bruce Momjian wrote:
James Mansion wrote:
I think you have your head in the ground, but its your perogative.
*You* might not care, but anyone wanting to use thread-aware libraries
(and I'm *not* talking about threading in any Postgres code) will
certainly value it if they can do so with some sta
Note: I am resending this because the first never appeared after 40hrs.
HH
[EMAIL PROTECTED] wrote:
Hello
i have a python script to update 60 rows to one table from a csv file in my
postgres database and it takes me 5 hours to do the transaction...
I'm on debian etch with 8.1 postgres serv
Roberts, Jon wrote:
Alvaro Herrera pointed out that pg_read_file requires superuser access which
these users won't have so revoking access to the function code should be
possible.
Joshua D. Drake suggested revoking pg_proc but that isn't the source code,
it just has the definition of the functio
>>> On Fri, Dec 14, 2007 at 5:59 PM, in message <[EMAIL PROTECTED]>,
Tom Lane <[EMAIL PROTECTED]> wrote:
> "Kevin Grittner" <[EMAIL PROTECTED]> writes:
>> Why double writes per read, plus massive writes at checkpoint?
>
> The double writes aren't surprising: freezing has to be WAL-logged,
> and
On Dec 17, 2007 8:11 AM, Roberts, Jon <[EMAIL PROTECTED]> wrote:
> Alvaro Herrera pointed out that pg_read_file requires superuser access which
> these users won't have so revoking access to the function code should be
> possible.
>
> Joshua D. Drake suggested revoking pg_proc but that isn't the so
Alvaro Herrera pointed out that pg_read_file requires superuser access which
these users won't have so revoking access to the function code should be
possible.
Joshua D. Drake suggested revoking pg_proc but that isn't the source code,
it just has the definition of the functions.
If it isn't a f
James Mansion wrote:
> I think you have your head in the ground, but its your perogative.
> *You* might not care, but anyone wanting to use thread-aware libraries
> (and I'm *not* talking about threading in any Postgres code) will
> certainly value it if they can do so with some stability.
I sugge
10 matches
Mail list logo
