"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> I seem to be getting virus emails that pretend to be one of your guys. eg.
> I get them from T.Ishii and N.Conway, etc. Anyone out there on the list who
> should perhaps scan their computer? :)
One of the nastier aspects of the Klez virus
"Robert E. Bruccoleri" <[EMAIL PROTECTED]> writes:
> On SGI multiprocessor machines, I suspect that a spinlock
> implementation of LWLockAcquire would give better performance than
> using IPC semaphores. Is there any specific reason that a spinlock
> could not be used in this context?
Are you co
Hi guys,
I seem to be getting virus emails that pretend to be one of your guys. eg.
I get them from T.Ishii and N.Conway, etc. Anyone out there on the list who
should perhaps scan their computer? :)
Chris
---(end of broadcast)---
TIP 5: Have y
On SGI multiprocessor machines, I suspect that a spinlock
implementation of LWLockAcquire would give better performance than
using IPC semaphores. Is there any specific reason that a spinlock
could not be used in this context?
+-++
Hi,
We have a query "select count(count(*)) from test group by
trunc(test_date)". This works fine with Oracle but when moving to postgres I
changed it to "select count(count(*)) from test group by date_trunc('day',
test_date)" but I get the following error
ERROR: Aggregate function calls may no
Try this:
SELECT count(*)
FROM (
SELECT count(*)
FROM test
GROUP BY date_trunc('day', test_date)
) as qry;
On Fri, 2002-07-26 at 16:03, Yuva Chandolu wrote:
> Hi,
>
> We have a query "select count(count(*)) from test group by
> trunc(test_date)". This works fi
On Fri, 26 Jul 2002, Jan Wieck wrote:
> What would be good is IMHO to have GRANT|REVOKE CONNECT which defaults
> to REVOKE, so only superusers and the DB owner can connect, but that the
> owner later can change it without the need to edit hba.conf.
Oh, yes. Me too please. I think something clo
Something to maybe add to the TODO list, if someone has the
time/inclination to work on it ...
The problem with the current auth system, as I see it, is that you can't
easily have seperate user lists and passwords per database ... its shared
across the system ...
The closest you can get is to h
On Fri, Jul 26, 2002 at 10:48:53 -0300,
"Marc G. Fournier" <[EMAIL PROTECTED]> wrote:
>
> Something to maybe add to the TODO list, if someone has the
> time/inclination to work on it ...
>
> The problem with the current auth system, as I see it, is that you can't
> easily have seperate user li
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> As an alternative syntax I can suggest
> SET name TO value [ ON COMMIT RESET ];
Ugh. Why can't we stick with SET LOCAL?
regards, tom lane
---(end of broadcast)---
TIP 6: Have
On Fri, 2002-07-26 at 12:55, Marc G. Fournier wrote:
> On Fri, 26 Jul 2002, Tom Lane wrote:
>
> > Rod Taylor <[EMAIL PROTECTED]> writes:
> > > This still doesn't allow john on db1 to be a different user than john on
> > > db2. To accomplish that (easily) we still need to install different
> > >
"Marc G. Fournier" wrote:
>
> Something to maybe add to the TODO list, if someone has the
> time/inclination to work on it ...
>
> The problem with the current auth system, as I see it, is that you can't
> easily have seperate user lists and passwords per database ... its shared
> across the sys
12 matches
Mail list logo
