Re: [HACKERS] Password sub-process ...
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 system ... I don't see a problem with that in general. Other databases (like Informix) do it even worse and you need a UNIX or NIS account where the password is held! 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. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Password sub-process ...
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 have a database defined as 'password' in
pg_hba.conf, with an external password file from pg_shadow, which, for the
most part, is good ... but it doesn't lend itself well to a 'hands off'
server ...
Right now, with v7.2, we have two 'sub-processes' that start up for stats
collection ... has anyone thought about adding a 3rd as a password server?
Basically, it would be used to manage the pg_hba.conf file itself *while*
the server is/was live ...
For instance, CREATE DATABASE would need to get extended to have
something like WITH AUTH '{trust|password|ident}' FROM 'IP' added to
it, which would add an appropriate line to pg_hba.conf ...
The database owner would have the ability to add users if (and only if)
the database was setup for 'password', and the password daemon would
automatically modify the password file(s) for that database ..
What would be even more cool ... to be able to do something like:
CREATE USER user FROM IP WITH PASSWORD password
which, if it didn't exist, would create a line in pg_hba.conf of:
hostdatabase ippassworddatabase
and create a database password file with that person in it ...
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [HACKERS] Password sub-process ...
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 close to this is coming with schemes - well at least my take on it indicates that. Rod -- Open Source Software - Sometimes you get more than you paid for... ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] regd count(count(*)) in group by
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 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 not be nested
Can some one help me...
Thanks
Yuva
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] regd count(count(*)) in group by
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 not be nested
Can some one help me...
Thanks
Yuva
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Question about LWLockAcquire's use of semaphores instead of spinlocks
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? +-++ | Robert E. Bruccoleri, Ph.D. | email: [EMAIL PROTECTED]| | P.O. Box 314| URL: http://www.congen.com/~bruc | | Pennington, NJ 08534|| +-++ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Password sub-process ...
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 instances for each database. Some people think that cross-database user names are a feature, not a bug. I cannot see any way to change that without creating huge backward-compatibility headaches --- and it's not at all clear to me that it's a step forward, anyway. I think that it might be worth adding a CONNECT privilege at the database level; that together with Bruce's recent revisions to pg_hba.conf ought to be a pretty good improvement. Also, I thnk I might have missed the point of the whole CONNECT privilege thing ... if I have two ppl named joe on the system, each with different passwords, how does the CONNECT know which one is the one that has access to that database? Well.. right now we call one db1_joe and db2_joe. I meant adding the ability to lock some users to specific DBs -- and only exist there. Authentication would use destination DB as well as username. Where DB is null, the user is a global user. Usernames would still be unique per database. ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] SET LOCAL again
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 you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Password sub-process ...
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 lists and passwords per database ... its shared across the system ... If you look at the 7.3 docs you will see that you will be able to restrict access to databases by user or group name. If you use group name and have one group per database you will be able to administer access pretty easily. If you have a lot of databases you can use group names matching database names and not have to touch your conf file when making new databases. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Virus Emails
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 you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
