Обсуждение: Open 7.3 items
Here are the open items for 7.3. We have one more month to address them
before beta.
---------------------------------------------------------------------------
P O S T G R E S Q L
7 . 3 O P E N I T E M S
Current at ftp://candle.pha.pa.us/pub/postgresql/open_items.
Source Code Changes
-------------------
Socket permissions - only install user can access db by defaultunix_socket_permissions in postgresql.conf
NAMEDATALEN - disk/performance penalty for increase, 64, 128?
FUNC_MAX_ARGS - disk/performance penalty for increase, 24, 32?
Point-in-time recovery - ready for 7.3?
Allow easy display of usernames in a group (pg_hba.conf uses groups now)
Reindex/btree shrinkage - does reindex need work, can btree be shrunk?
DROP COLUMN - ready?
CLUSTER - ready?
display locks - ready?
Win32 - timefame?
Prepared statements - ready?
Schema handling - ready? interfaces? client apps?
Dependency - pg_dump auto-create dependencies for 7.2.X data?
glibc and mktime() - fix?
Functions Returning Sets - done?
ecpg and bison issues - solved?
Documentation Changes
---------------------
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
> Schema handling - ready? interfaces? client apps? With schemas, how about settings for automatically creating a schema for a user when you create the user, etc. Chris
On Tuesday 30 July 2002 11:50 pm, Bruce Momjian wrote: > Here are the open items for 7.3. We have one more month to address them > before beta. > Source Code Changes > ------------------- Bruce, is the config file location stuff not being addressed? I remember Mark (mlw) had worked up the patch for a '-C' switch, there was discussion, etc. Did it not make the todo? If Peter or someone else doesn't beat me to it I might try my hand at that one, as I would dearly love to be able to decouple the config files from PGDATA. It has been discussed; consensus was not reached as I recall. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Lamar Owen wrote: > On Tuesday 30 July 2002 11:50 pm, Bruce Momjian wrote: > > Here are the open items for 7.3. We have one more month to address them > > before beta. > > > Source Code Changes > > ------------------- > > Bruce, is the config file location stuff not being addressed? I remember Mark > (mlw) had worked up the patch for a '-C' switch, there was discussion, etc. > Did it not make the todo? > > If Peter or someone else doesn't beat me to it I might try my hand at that > one, as I would dearly love to be able to decouple the config files from > PGDATA. It has been discussed; consensus was not reached as I recall. The issue was never resolved, so it did not make any lists. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Lamar Owen <lamar.owen@wgcr.org> writes:
> Bruce, is the config file location stuff not being addressed? ...
> If Peter or someone else doesn't beat me to it I might try my hand at that
> one, as I would dearly love to be able to decouple the config files from
> PGDATA. It has been discussed; consensus was not reached as I recall.
I believe that last part was the sticking point. If you can find some
consensus on how it ought to work, then go for it. My own opinion is
that there is nothing broken there; certainly nothing so broken that
we need to force a change under schedule pressure.
regards, tom lane
Tom Lane wrote: > Lamar Owen <lamar.owen@wgcr.org> writes: > > Bruce, is the config file location stuff not being addressed? ... > > If Peter or someone else doesn't beat me to it I might try my hand at that > > one, as I would dearly love to be able to decouple the config files from > > PGDATA. It has been discussed; consensus was not reached as I recall. > > I believe that last part was the sticking point. If you can find some > consensus on how it ought to work, then go for it. My own opinion is > that there is nothing broken there; certainly nothing so broken that > we need to force a change under schedule pressure. I don't feel we are under pressure. We have time to discuss and address it. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> ... My own opinion is
>> that there is nothing broken there; certainly nothing so broken that
>> we need to force a change under schedule pressure.
> I don't feel we are under pressure. We have time to discuss and address
> it.
Well, it's all a matter of how you look at it. Isn't the point of your
post that began this thread to start giving people a sense of time
pressure?
I agree that if we could quickly come to a resolution about how this
ought to work, there's plenty of time to go off and implement it. But
(1) we failed to come to a consensus before, so I'm not optimistic
than one will suddenly emerge now; (2) we've got a ton of other issues
that we *need* to deal with before beta. This one does not strike me
as a must-fix, and so I'm loathe to spend much development time on it
when there are so many open issues.
regards, tom lane
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Tom Lane wrote: > >> ... My own opinion is > >> that there is nothing broken there; certainly nothing so broken that > >> we need to force a change under schedule pressure. > > > I don't feel we are under pressure. We have time to discuss and address > > it. > > Well, it's all a matter of how you look at it. Isn't the point of your > post that began this thread to start giving people a sense of time > pressure? > > I agree that if we could quickly come to a resolution about how this > ought to work, there's plenty of time to go off and implement it. But > (1) we failed to come to a consensus before, so I'm not optimistic > than one will suddenly emerge now; (2) we've got a ton of other issues > that we *need* to deal with before beta. This one does not strike me > as a must-fix, and so I'm loathe to spend much development time on it > when there are so many open issues. Well, it is up to the individuals involved. If someone wants to deal with it, and gets a consensus, and comes up with a patch, let them. The list is for time pressure on those items. It does not affect new items. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Here are the open items for 7.3.
Some comments ...
> Socket permissions - only install user can access db by default
I do not agree with this goal.
> NAMEDATALEN - disk/performance penalty for increase, 64, 128?
> FUNC_MAX_ARGS - disk/performance penalty for increase, 24, 32?
At the moment I don't see a lot of solid evidence that increasing
NAMEDATALEN has any performance penalty. Someone reported about
a 10% slowdown on pgbench with NAMEDATALEN=128 ... but Neil Conway
tried to reproduce the result, and got about a 10% *speedup*.
Personally I think 10% is well within the noise spectrum for
pgbench, and so it's difficult to claim that we have established
any performance difference at all. I have not tried to measure
FUNC_MAX_ARGS differences.
> Point-in-time recovery - ready for 7.3?
At the moment, it doesn't exist at all. If patches appear, we can
review 'em, but right now there is nothing to debate.
> DROP COLUMN - ready?
I'm on it.
> Win32 - timefame?
I've seen nothing to make me think this will be ready for 7.3.
> Prepared statements - ready?
I think we're close there; the patch seems okay, we're just debating
minor syntax issues.
> Schema handling - ready? interfaces? client apps?
The backend will be ready (it's not quite yet). pg_dump is ready.
psql is very definitely not ready, nor is pgaccess. I don't know the
status for JDBC or ODBC; any comments? The other interface libraries
probably don't care.
> Dependency - pg_dump auto-create dependencies for 7.2.X data?
Huh?
> glibc and mktime() - fix?
We need a fix for this. Dunno what to do about it.
> ecpg and bison issues - solved?
Not yet :-(. Anyone have a line into the bison project?
Other things on my radar screen:
* I have about zero confidence in the recent tuple-header-size-reduction
patches.
* pg_conversion stuff --- do we understand this thing's behavior under
failure conditions? Does it work properly with namespaces and
dependencies?
* pg_dumpall probably ought to dump database privilege settings, also
per-user and per-database GUC settings.
* BeOS and QNX4 ports are busted.
* The whole area of which implicit coercions should be allowed is a
serious problem that we have not spent enough time on. There are
a number of cases in which CVS tip is clearly broken compared to
prior releases.
* Bear Giles' SSL patches seem to be causing unhappiness in some
quarters.
* libpqxx is not integrated into build process nor docs. It should
be integrated or reversed out before beta.
regards, tom lane
> -----Original Message----- > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > Sent: Tuesday, July 30, 2002 9:50 PM > To: Bruce Momjian > Cc: PostgreSQL-development > Subject: Re: [HACKERS] Open 7.3 items [snip] > > Win32 - timefame? I may be able to contribute the Win32 stuff we have done here. (Not sure of it, but they do seem more open to the idea now). It's only for 7.1.3, and so I am not sure how helpful it would be. There is also a bunch of stuff that looks like this in the code: #ifdef ICKY_WIN32_KLUDGE /* Bletcherous hack to make it work in Win32 goes here... */ #else /* Normal code goes here... */ #endif Let me know if you are interested.
> * pg_conversion stuff --- do we understand this thing's behavior under > failure conditions? As far as I know, automatic encoding conversion behaves well under failure conditions. > Does it work properly with namespaces and > dependencies? Yes. -- Tatsuo Ishii
add in 'fix pg_hba.conf / password issues' to that too :) On Tue, 30 Jul 2002, Bruce Momjian wrote: > > Here are the open items for 7.3. We have one more month to address them > before beta. > > --------------------------------------------------------------------------- > > P O S T G R E S Q L > > 7 . 3 O P E N I T E M S > > > Current at ftp://candle.pha.pa.us/pub/postgresql/open_items. > > Source Code Changes > ------------------- > Socket permissions - only install user can access db by default > unix_socket_permissions in postgresql.conf > NAMEDATALEN - disk/performance penalty for increase, 64, 128? > FUNC_MAX_ARGS - disk/performance penalty for increase, 24, 32? > Point-in-time recovery - ready for 7.3? > Allow easy display of usernames in a group (pg_hba.conf uses groups now) > Reindex/btree shrinkage - does reindex need work, can btree be shrunk? > DROP COLUMN - ready? > CLUSTER - ready? > display locks - ready? > Win32 - timefame? > Prepared statements - ready? > Schema handling - ready? interfaces? client apps? > Dependency - pg_dump auto-create dependencies for 7.2.X data? > glibc and mktime() - fix? > Functions Returning Sets - done? > ecpg and bison issues - solved? > > > Documentation Changes > --------------------- > > > -- > Bruce Momjian | http://candle.pha.pa.us > pgman@candle.pha.pa.us | (610) 853-3000 > + If your life is a hard drive, | 830 Blythe Avenue > + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly >
On Wed, 31 Jul 2002, Tom Lane wrote: > * libpqxx is not integrated into build process nor docs. It should > be integrated or reversed out before beta. I've requestsed that Jeorgen(sp?) move this over to GBorg ... its something that can, and should be, built seperately from the base distribution, along with at least a dozen other things we have bloating the distribution now :( but at least that one hasn't been integrated yet ... We got into 'creeping featurisms' in the beginning because we had no other really central location to put stuff ... we do now, and with better mechanisms in place for dealing with 'multiple maintainers' ... its about time we start to trim the fat, before we can't fit through the proverbial door anymore ... Peronally, I find it quite annoying to have to download the complete server distribution just to get libpq installed so that I can install mod_php4 ... and with all the talk about 'why mysql vs pgsql' that has been going on lately, its time to start look at how to make it easier to 'add a new interface' without having to download the whole distribution 'yet again' ...
> > Dependency - pg_dump auto-create dependencies for 7.2.X data? > > Huh? Taking a bunch of CREATE CONSTRAINT TRIGGERS and turning them into the proper pg_constraint entries... Chris
...
> I agree that if we could quickly come to a resolution about how this
> ought to work, there's plenty of time to go off and implement it. But
> (1) we failed to come to a consensus before, so I'm not optimistic
> than one will suddenly emerge now; (2) we've got a ton of other issues
> that we *need* to deal with before beta. This one does not strike me
> as a must-fix, and so I'm loathe to spend much development time on it
> when there are so many open issues.
afaict someone else volunteered to do the work. There is no lack of
consensus that this is a useful feature, at least among those who take
responsibility to package PostgreSQL for particular platforms. How about
letting them specify the requirements and if an acceptable solution
emerges soon, we'll have it for 7.3...
- Thomas
>> Schema handling - ready? interfaces? client apps? > status for JDBC or ODBC; any comments? The other interface libraries > probably don't care. What about DBD::Pg? -- Kaare Rasmussen --Linux, spil,-- Tlf: 3816 2582 Kaki Data tshirts, merchandize Fax: 3816 2501 Howitzvej 75 Åben 12.00-18.00 Web: www.suse.dk 2000 Frederiksberg Lørdag 12.00-16.00 Email:kar@kakidata.dk
Le Mercredi 31 Juillet 2002 05:50, Bruce Momjian a écrit : > Source Code Changes What about CREATE OR REPLACE VIEW which would be great for pgAdmin2. Thanks to all of you./Jean-Michel POURE
On Wed, Jul 31, 2002 at 02:11:06AM -0300, Marc G. Fournier wrote: > On Wed, 31 Jul 2002, Tom Lane wrote: > > * libpqxx is not integrated into build process nor docs. It should > > be integrated or reversed out before beta. > > I've requestsed that Jeorgen(sp?) move this over to GBorg ... its > something that can, and should be, built seperately from the base > distribution, along with at least a dozen other things we have bloating > the distribution now :( but at least that one hasn't been integrated yet > ... Mentioning that on -hackers would have been nice -- I've spent a while this week hacking autoconf / Makefiles to integrate libpqxx... The problem I have with removing libpqxx is that libpq++ is a far inferior C++ interface. If we leave libpq++ as the only C++ interface distributed with PostgreSQL, there will be a tendancy for people using PostgreSQL & C++ to use the C++ support included with the distribution. Similarly, the Perl interface included with PostgreSQL is widely regarded as inferior to DBD::Pg. If we're going to start removing interfaces, I'd vote for the removal of perl5 & libpq++ as well as libpqxx. We can add a section to the documentation listing the available language interfaces (for languages like Python, where several interfaces exist, this would probably be a good idea anyway). Cheers, Neil -- Neil Conway <neilconway@rogers.com> PGP Key ID: DB3C29FC
nconway@klamath.dyndns.org (Neil Conway) writes:
> Mentioning that on -hackers would have been nice -- I've spent a while
> this week hacking autoconf / Makefiles to integrate libpqxx...
Marc's opinion is not the same thing as a done deal ;-) --- we still
have to discuss this, and if someone's already doing the integration
work I think that's an important factor.
> If we're going to start removing interfaces, I'd vote for the removal of
> perl5 & libpq++ as well as libpqxx.
Agreed on that point. We shouldn't be promoting old, crufty interface
libraries when there are better ones available.
I would personally prefer to see libpqxx integrated now, and then we
could plan to remove libpq++ in a release or two (after giving people
a reasonable opportunity to switch over). If anyone still cares about
libpq++ at that point, it could be given a home on gborg.
One reason for wanting to integrate libpqxx is that I don't think we'll
find out anything about its portability until we get a lot of people
trying to build it. If it's a separate distro that won't happen quickly.
regards, tom lane
On Tue, Jul 30, 2002 at 11:50:38PM -0400, Bruce Momjian wrote: > NAMEDATALEN - disk/performance penalty for increase, 64, 128? In my personal testing, I've been unable to observe a significant performance impact (as Tom mentioned, I tried getting some profiling data with gprof + pgbench, and found that increasing NAMEDATALEN made things *faster*). Whether that is enough of an endorsement to make the change for 7.3, I'm not sure... > FUNC_MAX_ARGS - disk/performance penalty for increase, 24, 32? Until someone takes the time to determine what the performance implications of this change will be, I don't think we should change this. Given that no one has done any testing, I'm not convinced that there's a lot of demand for this anyway. > Point-in-time recovery - ready for 7.3? > Reindex/btree shrinkage - does reindex need work, can btree be shrunk? I think both of these should probably wait for 7.4 > display locks - ready? > Prepared statements - ready? Both of these are ready, only trivial changes are required. > Schema handling - ready? interfaces? client apps? Do we want all client interfaces / admin apps to be aware of schemas in time for beta 1, or is the plan to fix these during the beta cycle? Cheers, Neil -- Neil Conway <neilconway@rogers.com> PGP Key ID: DB3C29FC
On Wed, Jul 31, 2002 at 02:01:43AM -0300, Marc G. Fournier wrote: > add in 'fix pg_hba.conf / password issues' to that too :) I doubt that will make 7.3 -- the proposals I've seen on this topic require some reasonably complex additions to the authentication system. We also still need to hash out which design we're going to implement. Given that it's pretty esoteric, I'd prefer this wait for 7.4 Cheers, Neil -- Neil Conway <neilconway@rogers.com> PGP Key ID: DB3C29FC
nconway@klamath.dyndns.org (Neil Conway) writes:
>> FUNC_MAX_ARGS - disk/performance penalty for increase, 24, 32?
> Until someone takes the time to determine what the performance
> implications of this change will be, I don't think we should
> change this. Given that no one has done any testing, I'm not
> convinced that there's a lot of demand for this anyway.
The OpenACS guys really really wanted larger FUNC_MAX_ARGS (I think
they had some 25-arg functions). And we do see questions about
increasing the limit fairly often on the lists. I suspect we could
bump it up to 32 at little cost --- but someone should run some
experiments to verify.
regards, tom lane
On Wed, 31 Jul 2002, Neil Conway wrote: > On Wed, Jul 31, 2002 at 02:11:06AM -0300, Marc G. Fournier wrote: > > On Wed, 31 Jul 2002, Tom Lane wrote: > > > * libpqxx is not integrated into build process nor docs. It should > > > be integrated or reversed out before beta. > > > > I've requestsed that Jeorgen(sp?) move this over to GBorg ... its > > something that can, and should be, built seperately from the base > > distribution, along with at least a dozen other things we have bloating > > the distribution now :( but at least that one hasn't been integrated yet > > ... > > Mentioning that on -hackers would have been nice -- I've spent a while > this week hacking autoconf / Makefiles to integrate libpqxx... > > The problem I have with removing libpqxx is that libpq++ is a far > inferior C++ interface. If we leave libpq++ as the only C++ interface > distributed with PostgreSQL, there will be a tendancy for people > using PostgreSQL & C++ to use the C++ support included with the > distribution. Similarly, the Perl interface included with > PostgreSQL is widely regarded as inferior to DBD::Pg. Exactly what I mean ... we have *alot* of fat in the distribution ... stuff that almost nobody uses ... or stuff that is generally inferior to something else out there ... What I *want* to see is a *base* server distribution vs the client side code ... I *want* to be able to download libpq on a client machine to install mod_php4, for example, without having to download everything else that I'll never need ... > If we're going to start removing interfaces, I'd vote for the removal of > perl5 & libpq++ as well as libpqxx. We can add a section to the > documentation listing the available language interfaces (for languages > like Python, where several interfaces exist, this would probably be a > good idea anyway). Definitely ... python, tcl, pgaccess ... all of that needs to go ... they are "specialty" stuff that, in some cases, have nothing to do with the server itself .. Anything that can build *from* libpq already being installed (except for those that are required to admin the server (ie. psql, pg_dump, etc) should be yanked and maintained outside of the distribution ... if nobody is maintaining it, then obviously nobody is using it, so why carry it? We have the environment now to keep the development 'centralized' through GBorg, which also means that others can be provided with CVS access as maintainers, if, for instance, Joergen(sp?) wishes to bring someone else on board to help ...
> > Schema handling - ready? interfaces? client apps? > > The backend will be ready (it's not quite yet). pg_dump is ready. > psql is very definitely not ready, nor is pgaccess. I don't know the > status for JDBC or ODBC; any comments? The other interface libraries > probably don't care. > > > Dependency - pg_dump auto-create dependencies for 7.2.X data? > > Huh? There's still a problem with restoring blobs in a certain circumstance-- the attached script (run as the pg superuser) shows that there's either an inconsistency or a misunderstanding (on my part), resulting in a failed pg_restore. It seems that pg_restore isn't necessarily reconnecting as superuser after restoring a user owned table and before trying to restore pg_largeobject. This came to light specifically because I was trying to restore from a 7.2.1 dump file into the 7.3dev server, but this script is using all 7.3dev tools, refreshed from cvs this morning. -ron
Вложения
On Wed, 31 Jul 2002, Tom Lane wrote: > nconway@klamath.dyndns.org (Neil Conway) writes: > > Mentioning that on -hackers would have been nice -- I've spent a while > > this week hacking autoconf / Makefiles to integrate libpqxx... > > Marc's opinion is not the same thing as a done deal ;-) --- we still > have to discuss this, and if someone's already doing the integration > work I think that's an important factor. > > > If we're going to start removing interfaces, I'd vote for the removal of > > perl5 & libpq++ as well as libpqxx. > > Agreed on that point. We shouldn't be promoting old, crufty interface > libraries when there are better ones available. > > I would personally prefer to see libpqxx integrated now, and then we > could plan to remove libpq++ in a release or two (after giving people > a reasonable opportunity to switch over). If anyone still cares about > libpq++ at that point, it could be given a home on gborg. > > One reason for wanting to integrate libpqxx is that I don't think we'll > find out anything about its portability until we get a lot of people > trying to build it. If it's a separate distro that won't happen quickly. Who cares? Those that need a C++ interface will know where to find it, and will report bugs that they have ... why should it be tested on every platform when we *might* only have those on the Linux platform using it? What happens if/when libpqxx becomes the 'old, crufty interface' and something newer and shinier comes along? Where do we draw the line at what is in the distribution? For instance, why pgaccess vs a platform independent version of PgAdmin vs PHPPgAdmin? Hell, IMHO, PHPPgAdmin would most likely be more useful as more sites out there are running PHP then likely have TCL installed ... but someone that is using TCL/AolServer would definitely think otherwise ... By branching out the fat, we make it *easier* for someone to take on development of it ... would libpqxx ever have been developed if Joergen could have just worked on libpq++ in the first place, without having to submit patches? I really do not want to keep adding more users onto postgresql.org's servers just because "hey, their interface is cool and useful so let's add it into the main CVS repository and give them CVS access to save them having to submit patches" when we have a fully functioning collaborative development environment that gives them *more* then what we can give them now ... 1. the ability to pull in their own group of developers / committers on a per project basis 2. the ability to make releases *as required*, instead of having to wait for us to do the next release The benefit to us ... a much much smaller package of programs that have to be maintained and tested and debugged before a release ... Hell, how many packages do we currently have integrated with the whole distribution that rely *nothing* on the server other then to be able to use libpq to compile, that would benefit from being able to do releases? If, for instance, the libpq++ interface gets patched up to fix a race condition, or a vulnerability, the way things are right now, ppl have two choices: wait for v7.3 to be released sometime in October, or upgrade to the latest code via anon-cvs/cvsup ... and for package maintainers (rpm, deb, pkg), they pretty much have no choice but to wait ... Move libpq++ out as its own, independent project, and that patch would force a quick packaging and release of the new code, which those same package maintainers could jump on quickly and get out to *their* users ... How many packages/interfaces do we have 'integrated' right now that rely in no way on our release cycle *except* for the fact that they are integrated? The way we do things now made sense 7 years ago when we started out trying to get it as visible to the masses as possible ... and when we *didn't* have a clean/easy way to manage them externally ... it doesn't make any sense to do anymore, and hasn't for a fair time now ...
On Wed, 31 Jul 2002, Neil Conway wrote: > On Wed, Jul 31, 2002 at 02:01:43AM -0300, Marc G. Fournier wrote: > > add in 'fix pg_hba.conf / password issues' to that too :) > > I doubt that will make 7.3 -- the proposals I've seen on this topic > require some reasonably complex additions to the authentication > system. We also still need to hash out which design we're going > to implement. Given that it's pretty esoteric, I'd prefer this > wait for 7.4 Then, the current changes *should* be removed, as we have no idea how many sites out there we are going to break without that functionality ... I know I personally have 200+ servers that will all break as soon as I move to v7.3 with it as is :(
On Wed, Jul 31, 2002 at 02:08:33PM -0300, Marc G. Fournier wrote: > On Wed, 31 Jul 2002, Tom Lane wrote: > > One reason for wanting to integrate libpqxx is that I don't think we'll > > find out anything about its portability until we get a lot of people > > trying to build it. If it's a separate distro that won't happen quickly. > > Who cares? Those that need a C++ interface will know where to find it, > and will report bugs that they have ... why should it be tested on every > platform when we *might* only have those on the Linux platform using it? This seems a bad argument. You can't say "we support interface xyz" and never test it on anything except i80x86 Linux. Somebady comes along and tries to make it go on Solaris, and it doesn't work: poof, the cross-platform reputation that you and other have worked hard to burnish goes away. Never mind that it's only a client library. Besides, more generally, Postgres already has a reputation as being difficult to install. The proposal to separate out all the "non-basics" (I'm not even sure how one would draw that line: maybe a server-only package and a client-library package run through GBorg?) would mean that anyone wanting to do something moderately complicated would have a yet higher hurdle. Isn't that a problem? A -- ---- Andrew Sullivan 87 Mowat Avenue Liberty RMS Toronto, Ontario Canada <andrew@libertyrms.info> M6K 3E3 +1 416 646 3304 x110
I too do not like alot of bloat in the distribution, but I also agree with what Andrew is saying. Currently, at the FTP site, you can download the whole tar file, or in 4 separate tarballs. How hard would it be to create a separate tarball for client related packages? I am not sure if this would be a *great* solution, but it might be a good compromise. --brett On Wed, 2002-07-31 at 10:22, Andrew Sullivan wrote: > On Wed, Jul 31, 2002 at 02:08:33PM -0300, Marc G. Fournier wrote: > > On Wed, 31 Jul 2002, Tom Lane wrote: > > > > One reason for wanting to integrate libpqxx is that I don't think we'll > > > find out anything about its portability until we get a lot of people > > > trying to build it. If it's a separate distro that won't happen quickly. > > > > Who cares? Those that need a C++ interface will know where to find it, > > and will report bugs that they have ... why should it be tested on every > > platform when we *might* only have those on the Linux platform using it? > > This seems a bad argument. You can't say "we support interface xyz" > and never test it on anything except i80x86 Linux. Somebady comes > along and tries to make it go on Solaris, and it doesn't work: poof, > the cross-platform reputation that you and other have worked hard to > burnish goes away. Never mind that it's only a client library. > > Besides, more generally, Postgres already has a reputation as being > difficult to install. The proposal to separate out all the > "non-basics" (I'm not even sure how one would draw that line: maybe a > server-only package and a client-library package run through GBorg?) > would mean that anyone wanting to do something moderately complicated > would have a yet higher hurdle. Isn't that a problem? > > A > > -- > ---- > Andrew Sullivan 87 Mowat Avenue > Liberty RMS Toronto, Ontario Canada > <andrew@libertyrms.info> M6K 3E3 > +1 416 646 3304 x110 > > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org -- Brett Schwarz brett_schwarz AT yahoo.com
> Besides, more generally, Postgres already has a reputation as being > difficult to install. The proposal to separate out all the > "non-basics" (I'm not even sure how one would draw that line: maybe a > server-only package and a client-library package run through GBorg?) > would mean that anyone wanting to do something moderately complicated > would have a yet higher hurdle. Isn't that a problem? When you install freebsd or linux, is it a problem that all the perl modules you need have to fetched from cpan ? why can't they call just be part of the OS ?' likewise with dns servers, samba, apache etc.. this is a bit of a stretched example but the point is the same. Personall, I'd live to just be able to download the server with pg_dump psql etc.. But that's just me for what it's worth. jeff.
On Wed, 31 Jul 2002, Andrew Sullivan wrote: > On Wed, Jul 31, 2002 at 02:08:33PM -0300, Marc G. Fournier wrote: > > On Wed, 31 Jul 2002, Tom Lane wrote: > > > > One reason for wanting to integrate libpqxx is that I don't think we'll > > > find out anything about its portability until we get a lot of people > > > trying to build it. If it's a separate distro that won't happen quickly. > > > > Who cares? Those that need a C++ interface will know where to find it, > > and will report bugs that they have ... why should it be tested on every > > platform when we *might* only have those on the Linux platform using it? > > This seems a bad argument. You can't say "we support interface xyz" > and never test it on anything except i80x86 Linux. Somebady comes > along and tries to make it go on Solaris, and it doesn't work: poof, > the cross-platform reputation that you and other have worked hard to > burnish goes away. Never mind that it's only a client library. This is my point, actually ... there are *two* things we should be guarantee'ng to work cross-platform: the server and libpq ... (note that with 'the server', I'm including the administrative commands and scripts, like psql and initdb) ... Take a look at libpq++ as a perfect example ... we've been distributing that forever, but Tom himself states its 'old and crufty' ... but its also the "officially supported version", so its what ppl generally use ... We should be focusing on "the server", not the "clients" ... Another point ... we have a load of stuff in contrib ... originally, contrib was meant basically as a temporary storage while we decide if we put it into the mainstream, and its grown into "if we have nowhere else to put it, shove it in here and forget it" ... how many ppl know if all of those that are in there even *work*? We know they compile, but do they actually work? > Besides, more generally, Postgres already has a reputation as being > difficult to install. The proposal to separate out all the "non-basics" > (I'm not even sure how one would draw that line: maybe a server-only > package and a client-library package run through GBorg?) would mean that > anyone wanting to do something moderately complicated would have a yet > higher hurdle. Isn't that a problem? Like what? I work at a local University and am slowly getting PgSQL used for more and more things ... I have one server that is the database server, but everything else connects to that ... As it is now, I have to download the whole distribution, configure the whole distribution, compile it and then install .. which, of course, installs a bunch of stuff that I just don't need (initdb, psql, libpq++, etc, etc) ... all I need is libpq.a ... How many thousands of web sites out there don't offer PgSQL due to teh hassle? Everyone is arguing 'why mysql vs pgsql?' ... if we had a simple 'libpq.tar.gz' that could be downloaded, nice and small, then we've just made enabling PgSQL by default in mod_php4 brain dead ...
On Wed, Jul 31, 2002 at 02:36:43PM -0300, Jeff MacDonald wrote: > > When you install freebsd or linux, is it a problem that all the > perl modules you need have to fetched from cpan ? why can't they > call just be part of the OS ?' Well, not just part of the OS, but part of Perl. And after all, Perl _does_ include a fabulous variety of built-in modules. > likewise with dns servers, samba, apache etc.. this is a bit of a stretched > example > but the point is the same. Actually, the comparison is apt. There's a reason people suggest using your distribution's PHP or Zope or what-have-you packages, rather than installing from source: an inexperienced user with these packages could easily spend several days trying to figure out all the bits to install. Obviously, such people are new users, and a learning curve is expected. But given recent hand-wringing about the relative "mind-share" of Postgres &c., it seems perverse to make a new user have to find out (probably by asking on a mailing list) that basic stuff like client libraries are a whole separate package, which needs to be dealt with separately. It _would_ be nice, though, to be able to get just the client stuff for sure. And maybe the separation is worth it; I just want to be sure that people know the effect on users. A -- ---- Andrew Sullivan 87 Mowat Avenue Liberty RMS Toronto, Ontario Canada <andrew@libertyrms.info> M6K 3E3 +1 416 646 3304 x110
On Wed, Jul 31, 2002 at 03:11:40PM -0300, Marc G. Fournier wrote: > hassle? Everyone is arguing 'why mysql vs pgsql?' ... if we had a simple > 'libpq.tar.gz' that could be downloaded, nice and small, then we've just > made enabling PgSQL by default in mod_php4 brain dead ... Sorry, I think I wasn't making myself clear. I think that's a splendid idea. But I'm not sure it's worth paying for it by making users who want the whole thing download multiple packages. Maybe I'm alone in thinking that, however, and it's not like I feel terribly strongly about it. A -- ---- Andrew Sullivan 87 Mowat Avenue Liberty RMS Toronto, Ontario Canada <andrew@libertyrms.info> M6K 3E3 +1 416 646 3304 x110
Andrew Sullivan wrote: > Sorry, I think I wasn't making myself clear. I think that's a > splendid idea. But I'm not sure it's worth paying for it by making > users who want the whole thing download multiple packages. Maybe I'm > alone in thinking that, however, and it's not like I feel terribly > strongly about it. How much work is to make two packages - 'core' and 'complete'. Plus additional package called 'util' = 'complete' minus 'core'.
> How many thousands of web sites out there don't offer PgSQL due to teh > hassle? Everyone is arguing 'why mysql vs pgsql?' ... if we had a simple > 'libpq.tar.gz' that could be downloaded, nice and small, then we've just > made enabling PgSQL by default in mod_php4 brain dead ... Case in point, I just installed FreeBSD 4.6 on a machine, i chose to install mod_php from /stand/sysinstall. It ofcourse installed php, with mysql as a dependency, i was annoyed, but when i looked at what was actually installed, it was just "mysql client". The actually server did not get installed at all. Jeff.
Tom Lane wrote: > > Socket permissions - only install user can access db by default > > I do not agree with this goal. OK, this is TODO item: * Make single-user local access permissions the default by limiting permissions on the socket file (Peter E) Right now, we effectively install initdb as though we are creating a world-writeable directory on the machine. (Sure, the directory is locked down, but by setting PGUSER you can connect to the database as anyone.) I don't know any other software that does this, and I can't see how we can justify the current behavior. Another idea is to change pg_hba.conf to not default to 'trust' but then the installing user is going to have to choose a password. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Tom Lane wrote: > > NAMEDATALEN - disk/performance penalty for increase, 64, 128? > > FUNC_MAX_ARGS - disk/performance penalty for increase, 24, 32? > > At the moment I don't see a lot of solid evidence that increasing > NAMEDATALEN has any performance penalty. Someone reported about > a 10% slowdown on pgbench with NAMEDATALEN=128 ... but Neil Conway > tried to reproduce the result, and got about a 10% *speedup*. > Personally I think 10% is well within the noise spectrum for > pgbench, and so it's difficult to claim that we have established > any performance difference at all. I have not tried to measure > FUNC_MAX_ARGS differences. Yes, we need someone to benchmark both the NAMEDATALEN and FUNC_MAX_ARGS to prove we are not causing performance problems. Once that is done, the default limits can be easily increased. I was thinking 64 for NAMEDATALEN and 32 for FUNC_MAX_ARGS, effectively doubling both. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Yes, we need someone to benchmark both the NAMEDATALEN and FUNC_MAX_ARGS
> to prove we are not causing performance problems. Once that is done,
> the default limits can be easily increased. I was thinking 64 for
> NAMEDATALEN and 32 for FUNC_MAX_ARGS, effectively doubling both.
The SQL spec says NAMEDATALEN shall be 128 (or at least 128, too lazy
to look). If we're gonna change it then I think we should really try
to go to 128.
regards, tom lane
On Wed, Jul 31, 2002 at 03:30:30PM -0400, Bruce Momjian wrote: > Yes, we need someone to benchmark both the NAMEDATALEN and FUNC_MAX_ARGS > to prove we are not causing performance problems. Once that is done, > the default limits can be easily increased. I was thinking 64 for > NAMEDATALEN and 32 for FUNC_MAX_ARGS, effectively doubling both. If we're going to change NAMEDATALEN, we should probably set it to 128, as that's what SQL99 requires. Cheers, Neil -- Neil Conway <neilconway@rogers.com> PGP Key ID: DB3C29FC
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
> Socket permissions - only install user can access db by default
>>
>> I do not agree with this goal.
> OK, this is TODO item:
> * Make single-user local access permissions the default by limiting
> permissions on the socket file (Peter E)
Yes, I know what the TODO item says, and I disagree with it.
If we make the default permissions 700, then it's impossible to access
the database unless you run as the database owner. This is not a
security improvement --- it's more like claiming that a Linux system
would be more secure if you got rid of ordinary users and did all your
work as root. We should *not* encourage people to operate that way.
(It's certainly unworkable for RPM distributions anyway; only a user
who is hand-building a test installation under his own account would
possibly think that this is a useful default.)
I could see a default setup that made the permissions 770, allowing
access to anyone in the postgres group; that would at least bear some
slight resemblance to a workable production setup. However, this
assumes that the DBA has root privileges, else he'll not be able to
add/remove users from the postgres group. Also, on systems where users
all belong to the same "users" group, 770 isn't really better than 777.
The bottom line here is that there isn't any default protection setup
that is really widely useful. Everyone's got to adjust the thing to
fit their own circumstances. I'd rather see us spend more documentation
effort on pointing this out and explaining the alternatives, and not
think that we can solve the problem by making the default installation
so tight as to be useless.
regards, tom lane
> Another idea is to change pg_hba.conf to not default to 'trust' but then > the installing user is going to have to choose a password. I like this approach. Set it to password (or md5) on local, and force the request of a password during initdb. If for some reason they forget their password, they simply bump it to trust on local for the 1 minute it takes to change it back.
>> Another idea is to change pg_hba.conf to not default to 'trust' but then
>> the installing user is going to have to choose a password.
Well, initdb already has an option to request a password. It would
perhaps make sense for initdb to alter the installed pg_hba.conf file
to select local md5 mode instead of local trust mode when this option is
specified.
> I like this approach. Set it to password (or md5) on local, and force
> the request of a password during initdb.
I don't like "forcing" people to do anything, especially not things that
aren't necessarily useful to them. On a single-user machine there is
no advantage to using database passwords.
regards, tom lane
Tom Lane wrote: > > Point-in-time recovery - ready for 7.3? > > At the moment, it doesn't exist at all. If patches appear, we can > review 'em, but right now there is nothing to debate. Yes, I listed it just to keep it on the radar. > > Win32 - timefame? > > I've seen nothing to make me think this will be ready for 7.3. Same. > > Schema handling - ready? interfaces? client apps? > > The backend will be ready (it's not quite yet). pg_dump is ready. > psql is very definitely not ready, nor is pgaccess. I don't know the > status for JDBC or ODBC; any comments? The other interface libraries > probably don't care. We should generate a list of subitems here. > > Dependency - pg_dump auto-create dependencies for 7.2.X data? > > Huh? Can we create table/sequence dependency linking on loads; same with other dependencies? If not, we are going to have trouble with the dependency code only working some times. This could be a serious confusion for users. We coded some of our stuff assuming the linkage will always be present, but a load from 7.2 may not have it. What are the ramifications? > > glibc and mktime() - fix? > > We need a fix for this. Dunno what to do about it. I have proposed a fix of placing a fixed mktime earlier in the link line but no one has supplied a fixed mktime for me. > Other things on my radar screen: > > * I have about zero confidence in the recent tuple-header-size-reduction > patches. I have great confidence Manfred Koizar and his work. I know you want some checks added to the code and he will do that when he returns. I will mention this in the open items list. improve macros in new tuple header code > > * pg_conversion stuff --- do we understand this thing's behavior under > failure conditions? Does it work properly with namespaces and > dependencies? Seems Tatsuo says it is OK. > * pg_dumpall probably ought to dump database privilege settings, also > per-user and per-database GUC settings. Added: have pg_dumpall dump out db privilege and per-user/db settings > > * BeOS and QNX4 ports are busted. Added: fix BeOS and QNX4 ports > * The whole area of which implicit coercions should be allowed is a > serious problem that we have not spent enough time on. There are > a number of cases in which CVS tip is clearly broken compared to > prior releases. Oh. I didn't know that. Added: fix implicit type coercions that are worse > > * Bear Giles' SSL patches seem to be causing unhappiness in some > quarters. I believe it is only the interfaces/ssl directory I created from his patch when I didn't know what to do with it. I wanted to remove it but someone said it was good stuff and we should give the author until beta to address it. Added to TODO: remove interfaces/ssl if not improved > > * libpqxx is not integrated into build process nor docs. It should > be integrated or reversed out before beta. Added: integrate or remove new libpqxx -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
If you can contribute it, I think it would be valuable to the two other Win32 projects that are working on porting the 7.3 code to Win32. I don't think they will have any code ready for 7.3 but they may have a few pieces they want to get in to make their 7.3 patching job easier, like renaming macros or variables or something. --------------------------------------------------------------------------- Dann Corbit wrote: > > -----Original Message----- > > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > > Sent: Tuesday, July 30, 2002 9:50 PM > > To: Bruce Momjian > > Cc: PostgreSQL-development > > Subject: Re: [HACKERS] Open 7.3 items > [snip] > > > > Win32 - timefame? > > I may be able to contribute the Win32 stuff we have done here. (Not > sure of it, but they do seem more open to the idea now). It's only for > 7.1.3, and so I am not sure how helpful it would be. There is also a > bunch of stuff that looks like this in the code: > > #ifdef ICKY_WIN32_KLUDGE > /* Bletcherous hack to make it work in Win32 goes here... */ > #else > /* Normal code goes here... */ > #endif > > Let me know if you are interested. > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Neil Conway wrote: > On Wed, Jul 31, 2002 at 03:30:30PM -0400, Bruce Momjian wrote: > > Yes, we need someone to benchmark both the NAMEDATALEN and FUNC_MAX_ARGS > > to prove we are not causing performance problems. Once that is done, > > the default limits can be easily increased. I was thinking 64 for > > NAMEDATALEN and 32 for FUNC_MAX_ARGS, effectively doubling both. > > If we're going to change NAMEDATALEN, we should probably set it to 128, > as that's what SQL99 requires. OK, updated to show only 128. Do we need more performance testing? I am unclear on that. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Christopher Kings-Lynne wrote: > > > Dependency - pg_dump auto-create dependencies for 7.2.X data? > > > > Huh? > > Taking a bunch of CREATE CONSTRAINT TRIGGERS and turning them into the > proper pg_constraint entries... Description updated: Dependency - have pg_dump auto-create dependencies when loading7.2.X data? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Thomas Lockhart wrote: > ... > > I agree that if we could quickly come to a resolution about how this > > ought to work, there's plenty of time to go off and implement it. But > > (1) we failed to come to a consensus before, so I'm not optimistic > > than one will suddenly emerge now; (2) we've got a ton of other issues > > that we *need* to deal with before beta. This one does not strike me > > as a must-fix, and so I'm loathe to spend much development time on it > > when there are so many open issues. > > afaict someone else volunteered to do the work. There is no lack of > consensus that this is a useful feature, at least among those who take > responsibility to package PostgreSQL for particular platforms. How about > letting them specify the requirements and if an acceptable solution > emerges soon, we'll have it for 7.3... Added to open items: allow specification of configuration files in a different directory -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Neil Conway wrote: > On Tue, Jul 30, 2002 at 11:50:38PM -0400, Bruce Momjian wrote: > > NAMEDATALEN - disk/performance penalty for increase, 64, 128? > > In my personal testing, I've been unable to observe a significant > performance impact (as Tom mentioned, I tried getting some profiling > data with gprof + pgbench, and found that increasing NAMEDATALEN made > things *faster*). Whether that is enough of an endorsement to make > the change for 7.3, I'm not sure... OK, do we need to test further or just bump it to 128? > > FUNC_MAX_ARGS - disk/performance penalty for increase, 24, 32? > > Until someone takes the time to determine what the performance > implications of this change will be, I don't think we should > change this. Given that no one has done any testing, I'm not > convinced that there's a lot of demand for this anyway. I am going to list only 32 as an option. I think it needs to be at least that high for OpenACS. > > Point-in-time recovery - ready for 7.3? > > Reindex/btree shrinkage - does reindex need work, can btree be shrunk? > > I think both of these should probably wait for 7.4 Probably. We will just keep them on the radar. > > Schema handling - ready? interfaces? client apps? > > Do we want all client interfaces / admin apps to be aware of schemas in > time for beta 1, or is the plan to fix these during the beta cycle? Ideally, before beta or people can't really test them. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Marc G. Fournier wrote: > On Wed, 31 Jul 2002, Neil Conway wrote: > > > On Wed, Jul 31, 2002 at 02:01:43AM -0300, Marc G. Fournier wrote: > > > add in 'fix pg_hba.conf / password issues' to that too :) > > > > I doubt that will make 7.3 -- the proposals I've seen on this topic > > require some reasonably complex additions to the authentication > > system. We also still need to hash out which design we're going > > to implement. Given that it's pretty esoteric, I'd prefer this > > wait for 7.4 > > Then, the current changes *should* be removed, as we have no idea how many > sites out there we are going to break without that functionality ... I > know I personally have 200+ servers that will all break as soon as I move > to v7.3 with it as is :( OK, I have thought about this. First, a possible solution would be to have a GUC variable that prepends the dbname to all username specifications, so the username becomes dbname.username. When you CREATE USER "test", it actually does CREATE USER "dbname.test". Same with ALTER/DROP user and lookups in pg_hba.conf and authentication. Basically it gives us a per-db user namespace. Only the superuser has a non-db qualified name. (Actually, createuser script would fail because it connects only to template1. You would have to use psql and CREATE USER. Probably other things would fail too.) As for 7.3, maybe we can get that done in time of everyone likes it. If we can't, what do we do? Do we re-add the secondary password file stuff that most people don't like? My big question is how many other PostgreSQL users figured out they could use the secondary password file for username/db restrictions? I never thought of it myself. Maybe I should ask on general. Marc, you do have a workaround for 7.3 using your IP's, right, or is there a problem with the password having to be the same for different hosts with the same username? If Marc is the only one, and he has a workaround, we may just go ahead and leave it for 7.4. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Added to open items list: handle lack of secondary passwords --------------------------------------------------------------------------- Marc G. Fournier wrote: > > add in 'fix pg_hba.conf / password issues' to that too :) > > On Tue, 30 Jul 2002, Bruce Momjian wrote: > > > > > Here are the open items for 7.3. We have one more month to address them > > before beta. > > > > --------------------------------------------------------------------------- > > > > P O S T G R E S Q L > > > > 7 . 3 O P E N I T E M S > > > > > > Current at ftp://candle.pha.pa.us/pub/postgresql/open_items. > > > > Source Code Changes > > ------------------- > > Socket permissions - only install user can access db by default > > unix_socket_permissions in postgresql.conf > > NAMEDATALEN - disk/performance penalty for increase, 64, 128? > > FUNC_MAX_ARGS - disk/performance penalty for increase, 24, 32? > > Point-in-time recovery - ready for 7.3? > > Allow easy display of usernames in a group (pg_hba.conf uses groups now) > > Reindex/btree shrinkage - does reindex need work, can btree be shrunk? > > DROP COLUMN - ready? > > CLUSTER - ready? > > display locks - ready? > > Win32 - timefame? > > Prepared statements - ready? > > Schema handling - ready? interfaces? client apps? > > Dependency - pg_dump auto-create dependencies for 7.2.X data? > > glibc and mktime() - fix? > > Functions Returning Sets - done? > > ecpg and bison issues - solved? > > > > > > Documentation Changes > > --------------------- > > > > > > -- > > Bruce Momjian | http://candle.pha.pa.us > > pgman@candle.pha.pa.us | (610) 853-3000 > > + If your life is a hard drive, | 830 Blythe Avenue > > + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 3: if posting/reading through Usenet, please send an appropriate > > subscribe-nomail command to majordomo@postgresql.org so that your > > message can get through to the mailing list cleanly > > > > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> > psql is very definitely not ready, nor is pgaccess. I could not really trace who said this. To my understanding nobody is currently testing how pgaccess is dealing with 7.3 Am I wrong? Most problems we try to address now are related to pgaccess working on most platforms (Brett fights with the dlls, there are some Mac OS X efforts) and improve the usability (help upon connection failure, etc.) There are many new features people write, but this has not much to do with 7.3 in a direct way. Now in addition to the bugzilla and the developers@pgaccess.org mailing list, there is also a wiki http://www.pgaccess.org/wiki/ as a channel for filing ideas and wishes. Please, feel free to use it. Iavor
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Tom Lane wrote: > > Socket permissions - only install user can access db by default > >> > >> I do not agree with this goal. > > > OK, this is TODO item: > > > * Make single-user local access permissions the default by limiting > > permissions on the socket file (Peter E) > > Yes, I know what the TODO item says, and I disagree with it. > > If we make the default permissions 700, then it's impossible to access > the database unless you run as the database owner. This is not a > security improvement --- it's more like claiming that a Linux system > would be more secure if you got rid of ordinary users and did all your > work as root. We should *not* encourage people to operate that way. > (It's certainly unworkable for RPM distributions anyway; only a user > who is hand-building a test installation under his own account would > possibly think that this is a useful default.) I hope they would loosen the default in postgresql.conf rather than having everyone come in as the same user. By the time you create new user accounts, it is trivial to modify postgresql.conf. > I could see a default setup that made the permissions 770, allowing > access to anyone in the postgres group; that would at least bear some > slight resemblance to a workable production setup. However, this > assumes that the DBA has root privileges, else he'll not be able to > add/remove users from the postgres group. Also, on systems where users > all belong to the same "users" group, 770 isn't really better than 777. Yes, groups are nice, but in most cases with a group 'users', it is the same as world-writable. > The bottom line here is that there isn't any default protection setup > that is really widely useful. Everyone's got to adjust the thing to > fit their own circumstances. I'd rather see us spend more documentation > effort on pointing this out and explaining the alternatives, and not > think that we can solve the problem by making the default installation > so tight as to be useless. I think we are much safer shipping as secure and asking people to loosen it if they want wider access. I can imagine a Bugtrack item for PostgreSQL where they report we ship wide-open for local users. They have already reported we don't encrypt our passwords, and we are dealing with that. You can say that we tell people to change the default, but if we install that way, they have a legitimate grip, and PostgreSQL has a perception problem. The default unix permissions are world-readable, owner-writable. We ship with world-read/write. I know of _no_ other software that does that and I can't see how we get away with it. I will also add that I am the biggest proponent of tightening things up and on one else seems to be as concerned about it. I am not sure why. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Tom Lane wrote: > >> Another idea is to change pg_hba.conf to not default to 'trust' but then > >> the installing user is going to have to choose a password. > > Well, initdb already has an option to request a password. It would > perhaps make sense for initdb to alter the installed pg_hba.conf file > to select local md5 mode instead of local trust mode when this option is > specified. > > > I like this approach. Set it to password (or md5) on local, and force > > the request of a password during initdb. > > I don't like "forcing" people to do anything, especially not things that > aren't necessarily useful to them. On a single-user machine there is > no advantage to using database passwords. Yes, on a single-user machine, socket permissions are a better approach. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Andrew Sullivan wrote: > Actually, the comparison is apt. There's a reason people suggest > using your distribution's PHP or Zope or what-have-you packages, > rather than installing from source: an inexperienced user with these > packages could easily spend several days trying to figure out all the > bits to install. Obviously, such people are new users, and a > learning curve is expected. But given recent hand-wringing about the > relative "mind-share" of Postgres &c., it seems perverse to make a > new user have to find out (probably by asking on a mailing list) that > basic stuff like client libraries are a whole separate package, which > needs to be dealt with separately. It _would_ be nice, though, to be > able to get just the client stuff for sure. And maybe the separation > is worth it; I just want to be sure that people know the effect on > users. I have already provide Marc with a script needed to make an interfaces-only tarball. I was about 1/10th the size of the full tarball. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> As for 7.3, maybe we can get that done in time of everyone > likes it. If > we can't, what do we do? Do we re-add the secondary password > file stuff > that most people don't like? My big question is how many other > PostgreSQL users figured out they could use the secondary > password file > for username/db restrictions? I never thought of it myself. Maybe I > should ask on general. Unless I'm misunderstanding you, we use it and like it. We have several servers on one machine that all access the same password file (we have it softlinked). If we need to create a user that accesses only one cluster, then they get added to the file and created in the specific cluster. If that user then needs access to a different cluster, they just need to be added to the new cluster. The reason this is beneficial for us is because we then have the ability to have postgres only user accounts, as well as accounts from YP. When the YP user changes their unix password in YP, their postgres db account password changes as well (via cronjob). There are fewer passwords for them to manage in this way, but we still get the benefit of greater separation between clusters. Let me know if you want more information about how we use it (or if I misunderstood). What is it that people _don't_ like? -ron
Ron Snyder wrote: > > As for 7.3, maybe we can get that done in time of everyone > > likes it. If > > we can't, what do we do? Do we re-add the secondary password > > file stuff > > that most people don't like? My big question is how many other > > PostgreSQL users figured out they could use the secondary > > password file > > for username/db restrictions? I never thought of it myself. Maybe I > > should ask on general. > > Unless I'm misunderstanding you, we use it and like it. We have several > servers on one machine that all access the same password file (we have it > softlinked). If we need to create a user that accesses only one cluster, > then they get added to the file and created in the specific cluster. If > that user then needs access to a different cluster, they just need to be > added to the new cluster. > > The reason this is beneficial for us is because we then have the ability to > have postgres only user accounts, as well as accounts from YP. When the YP > user changes their unix password in YP, their postgres db account password > changes as well (via cronjob). > > There are fewer passwords for them to manage in this way, but we still get > the benefit of greater separation between clusters. > > Let me know if you want more information about how we use it (or if I > misunderstood). What is it that people _don't_ like? OK, how do secondary passwords work in pg_hba.conf. It requires clear-text 'password', right, because the password is already crypt-ed in the file. Here you are using it for something different, where one file is used for multiple clusters. Interesting. The current code allows you to point to a file for a list of users, which could be symlinked, so that is handled. The only part not handled is the password part. One idea I had was to look for a colon in the username, and if I see one, I assume everything after the colon is a password. Would that work for you? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Tom Lane writes: > > Socket permissions - only install user can access db by default > > I do not agree with this goal. It is my understanding that there is currently a lot of criticism that the default setup is open to all local users. This is nearly the same as having the data area files themselves world-writable by default. Maybe changing the default socket permissions isn't the appropriate measure, but I feel something ought to be done. -- Peter Eisentraut peter_e@gmx.net
> OK, how do secondary passwords work in pg_hba.conf. It requires > clear-text 'password', right, because the password is already crypt-ed > in the file. I presume that you're referring to passwords being transmitted clear text? > One idea I had was to look for a colon in the username, and if I see > one, I assume everything after the colon is a password. > Would that work > for you? It would as long as there was an assumption (or method to specify) that the stuff after the colon is a crypt()ed password. Our method to generate the password file is to 'ypcat passwd > /db/etc/password; cat /db/etc/pg-only-passwords >> /db/etc/password'. We could very easily only pull only the fields we care about from our yp passwd file. I suppose I should also mention that we're not wedded to this method-- we've just found it convenient. If we needed to script something else up to connect to the databases and set passwords, we could do that too, it would just be a bit more work. -ron
Ron Snyder wrote: > > OK, how do secondary passwords work in pg_hba.conf. It requires > > clear-text 'password', right, because the password is already crypt-ed > > in the file. > > I presume that you're referring to passwords being transmitted clear text? Yes, is that your pg_hba.conf line? 'password' is insecure over networks you don't trust. > > One idea I had was to look for a colon in the username, and if I see > > one, I assume everything after the colon is a password. > > Would that work > > for you? > > It would as long as there was an assumption (or method to specify) that the > stuff after the colon is a crypt()ed password. Our method to generate the It would be whatever password is specified on the pg_hba.conf line, 'password', 'crypt', or 'md5'. > password file is to 'ypcat passwd > /db/etc/password; cat > /db/etc/pg-only-passwords >> /db/etc/password'. We could very easily only > pull only the fields we care about from our yp passwd file. > > I suppose I should also mention that we're not wedded to this method-- we've > just found it convenient. If we needed to script something else up to > connect to the databases and set passwords, we could do that too, it would > just be a bit more work. OK. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> > Yes, is that your pg_hba.conf line? 'password' is insecure over > networks you don't trust. Yes, we're using 'password password' in our pg_hba.conf file. I trust my network (so far). -ron
Ron Snyder wrote: > > > > Yes, is that your pg_hba.conf line? 'password' is insecure over > > networks you don't trust. > > Yes, we're using 'password password' in our pg_hba.conf file. I trust my > network (so far). That is another major limitation to secondary password files. In fact, md5 will not even work because we assume the username is used as the salt for the md5 encryption. We don't store the salt as part of the encrypted password like crypt does. This was another reason secondary password files were discouraged. Let me look at adding the colon password capability and see what it looks like. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> Mentioning that on -hackers would have been nice -- I've spent a while > this week hacking autoconf / Makefiles to integrate libpqxx... > > The problem I have with removing libpqxx is that libpq++ is a far > inferior C++ interface. If we leave libpq++ as the only C++ interface > distributed with PostgreSQL, there will be a tendancy for people > using PostgreSQL & C++ to use the C++ support included with the > distribution. Similarly, the Perl interface included with > PostgreSQL is widely regarded as inferior to DBD::Pg. I think that if someone is actually working on libpqxx integration - then yeah, leave it in... Chris
On Wed, 31 Jul 2002, Bruce Momjian wrote: > OK, I have thought about this. First, a possible solution would be to > have a GUC variable that prepends the dbname to all username > specifications, so the username becomes dbname.username. When you > CREATE USER "test", it actually does CREATE USER "dbname.test". Same > with ALTER/DROP user and lookups in pg_hba.conf and authentication. > Basically it gives us a per-db user namespace. Only the superuser has a > non-db qualified name. (Actually, createuser script would fail because > it connects only to template1. You would have to use psql and CREATE > USER. Probably other things would fail too.) Sounds like a good solution that eliminates Tom's idea of going with 'local to database' pg_shadow files ... I like it ... > As for 7.3, maybe we can get that done in time of everyone likes it. > If we can't, what do we do? Do we re-add the secondary password file > stuff that most people don't like? My big question is how many other > PostgreSQL users figured out they could use the secondary password file > for username/db restrictions? I never thought of it myself. Maybe I > should ask on general. How many ppl that aren't subscribed to any of the lists are using this and are going to get burned royal when they upgrade to v7.3 without understanding it is gone? > Marc, you do have a workaround for 7.3 using your IP's, right, or is > there a problem with the password having to be the same for different > hosts with the same username? If Marc is the only one, and he has a > workaround, we may just go ahead and leave it for 7.4. No, unfortunately, I have at least one specific application that needs this :( IPs help reduce the impact of losing this, but with the growing difficultly and cost of acquiring new IPs, the IPs don't help much either :(
On Wed, 31 Jul 2002, Bruce Momjian wrote: > One idea I had was to look for a colon in the username, and if I see > one, I assume everything after the colon is a password. Would that work > for you? That would definitely work ... but I *really* like your GUC idea ... it would allow ppl to change passwords using simple SQL statements remotely, which the "old" password stuff didn't allow for ...
On Wed, 31 Jul 2002, Bruce Momjian wrote: > Ron Snyder wrote: > > > > > > Yes, is that your pg_hba.conf line? 'password' is insecure over > > > networks you don't trust. > > > > Yes, we're using 'password password' in our pg_hba.conf file. I trust my > > network (so far). > > That is another major limitation to secondary password files. In fact, > md5 will not even work because we assume the username is used as the > salt for the md5 encryption. We don't store the salt as part of the > encrypted password like crypt does. > > This was another reason secondary password files were discouraged. discouraged?? where? :)
> > As for 7.3, maybe we can get that done in time of everyone likes it. > > If we can't, what do we do? Do we re-add the secondary password file > > stuff that most people don't like? My big question is how many other > > PostgreSQL users figured out they could use the secondary password file > > for username/db restrictions? I never thought of it myself. Maybe I > > should ask on general. > > How many ppl that aren't subscribed to any of the lists are using this and > are going to get burned royal when they upgrade to v7.3 without > understanding it is gone? I agree with Marc here - compatibility in this area might just be very important (compared with some other lesser areas of incompatibility...) Chris
Marc G. Fournier wrote: > On Wed, 31 Jul 2002, Bruce Momjian wrote: > > > Ron Snyder wrote: > > > > > > > > Yes, is that your pg_hba.conf line? 'password' is insecure over > > > > networks you don't trust. > > > > > > Yes, we're using 'password password' in our pg_hba.conf file. I trust my > > > network (so far). > > > > That is another major limitation to secondary password files. In fact, > > md5 will not even work because we assume the username is used as the > > salt for the md5 encryption. We don't store the salt as part of the > > encrypted password like crypt does. > > > > This was another reason secondary password files were discouraged. > > discouraged?? where? :) Well. I meant that they had very limited usefulness. You had to trust your network. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Wed, 31 Jul 2002, Bruce Momjian wrote: > Marc G. Fournier wrote: > > On Wed, 31 Jul 2002, Bruce Momjian wrote: > > > > > Ron Snyder wrote: > > > > > > > > > > Yes, is that your pg_hba.conf line? 'password' is insecure over > > > > > networks you don't trust. > > > > > > > > Yes, we're using 'password password' in our pg_hba.conf file. I trust my > > > > network (so far). > > > > > > That is another major limitation to secondary password files. In fact, > > > md5 will not even work because we assume the username is used as the > > > salt for the md5 encryption. We don't store the salt as part of the > > > encrypted password like crypt does. > > > > > > This was another reason secondary password files were discouraged. > > > > discouraged?? where? :) > > Well. I meant that they had very limited usefulness. You had to trust > your network. that is the case for alot of software, and alot of networks nowadays are moving towards encrypted at the switch level, so the local network itself is considered to be 'secure' ... But, personally, you sooooooo sold me on that GUC thing that if we could implement that in time for v7.3, I think alot of ppl would find that *quite* valuable ...
Marc G. Fournier wrote: > On Wed, 31 Jul 2002, Bruce Momjian wrote: > > > Marc G. Fournier wrote: > > > On Wed, 31 Jul 2002, Bruce Momjian wrote: > > > > > > > Ron Snyder wrote: > > > > > > > > > > > > Yes, is that your pg_hba.conf line? 'password' is insecure over > > > > > > networks you don't trust. > > > > > > > > > > Yes, we're using 'password password' in our pg_hba.conf file. I trust my > > > > > network (so far). > > > > > > > > That is another major limitation to secondary password files. In fact, > > > > md5 will not even work because we assume the username is used as the > > > > salt for the md5 encryption. We don't store the salt as part of the > > > > encrypted password like crypt does. > > > > > > > > This was another reason secondary password files were discouraged. > > > > > > discouraged?? where? :) > > > > Well. I meant that they had very limited usefulness. You had to trust > > your network. > > that is the case for alot of software, and alot of networks nowadays are > moving towards encrypted at the switch level, so the local network itself > is considered to be 'secure' ... > > But, personally, you sooooooo sold me on that GUC thing that if we could > implement that in time for v7.3, I think alot of ppl would find that > *quite* valuable ... > I am working on it now. I decided against doing any kind of database prepending at the user level. You create the user as 'dbname.username'. That is clearer, rather than prepending based on the db you are connected to. The only code change is in the postmaster authentication lookup and ownership setting from the backend connection. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Wed, 31 Jul 2002, Bruce Momjian wrote: > Marc G. Fournier wrote: > > On Wed, 31 Jul 2002, Bruce Momjian wrote: > > > > > Marc G. Fournier wrote: > > > > On Wed, 31 Jul 2002, Bruce Momjian wrote: > > > > > > > > > Ron Snyder wrote: > > > > > > > > > > > > > > Yes, is that your pg_hba.conf line? 'password' is insecure over > > > > > > > networks you don't trust. > > > > > > > > > > > > Yes, we're using 'password password' in our pg_hba.conf file. I trust my > > > > > > network (so far). > > > > > > > > > > That is another major limitation to secondary password files. In fact, > > > > > md5 will not even work because we assume the username is used as the > > > > > salt for the md5 encryption. We don't store the salt as part of the > > > > > encrypted password like crypt does. > > > > > > > > > > This was another reason secondary password files were discouraged. > > > > > > > > discouraged?? where? :) > > > > > > Well. I meant that they had very limited usefulness. You had to trust > > > your network. > > > > that is the case for alot of software, and alot of networks nowadays are > > moving towards encrypted at the switch level, so the local network itself > > is considered to be 'secure' ... > > > > But, personally, you sooooooo sold me on that GUC thing that if we could > > implement that in time for v7.3, I think alot of ppl would find that > > *quite* valuable ... > > > > I am working on it now. I decided against doing any kind of database > prepending at the user level. You create the user as 'dbname.username'. > That is clearer, rather than prepending based on the db you are > connected to. The only code change is in the postmaster authentication > lookup and ownership setting from the backend connection. Okay, just a couple of questions ... if there any way of provide 'superuse' access a user of the database for creating new users? Say one creates a dbname.pgsql account, could it be given 'create user' privileges for other users with a prefix of dbname.*? and, what happens if one doesn't specify dbname.*? does that user become 'global', or have access to nothing?
Marc G. Fournier wrote: > > I am working on it now. I decided against doing any kind of database > > prepending at the user level. You create the user as 'dbname.username'. > > That is clearer, rather than prepending based on the db you are > > connected to. The only code change is in the postmaster authentication > > lookup and ownership setting from the backend connection. > > Okay, just a couple of questions ... if there any way of provide > 'superuse' access a user of the database for creating new users? Say one > creates a dbname.pgsql account, could it be given 'create user' privileges > for other users with a prefix of dbname.*? Uh, that will be tough. Super-user account will not be qualified by dbname for simplicity. > and, what happens if one doesn't specify dbname.*? does that user become > 'global', or have access to nothing? Access to nothing. I could actually try to quality by dbname.username, then fall back to just username, but that seems insecure. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Wed, 31 Jul 2002, Bruce Momjian wrote: > Marc G. Fournier wrote: > > > I am working on it now. I decided against doing any kind of database > > > prepending at the user level. You create the user as 'dbname.username'. > > > That is clearer, rather than prepending based on the db you are > > > connected to. The only code change is in the postmaster authentication > > > lookup and ownership setting from the backend connection. > > > > Okay, just a couple of questions ... if there any way of provide > > 'superuse' access a user of the database for creating new users? Say one > > creates a dbname.pgsql account, could it be given 'create user' privileges > > for other users with a prefix of dbname.*? > > Uh, that will be tough. > > Super-user account will not be qualified by dbname for simplicity. > > > and, what happens if one doesn't specify dbname.*? does that user become > > 'global', or have access to nothing? > > Access to nothing. I could actually try to quality by dbname.username, > then fall back to just username, but that seems insecure. No, that's cool ... just questions I thought of ... Okay ... hmmm ... just making sure that I understand ... I setup a server, when does this dbname.* come into play? Only if I enable password/md5 in pg_hba.conf for a specific database? all others would still use a plain 'username' still works? or are you getting rid of the 'global usernames' altogether (which is cool too, just want to clarify) ...
Marc G. Fournier wrote: > > Access to nothing. I could actually try to quality by dbname.username, > > then fall back to just username, but that seems insecure. > > No, that's cool ... just questions I thought of ... OK. > Okay ... hmmm ... just making sure that I understand ... I setup a server, > when does this dbname.* come into play? Only if I enable password/md5 in > pg_hba.conf for a specific database? all others would still use a plain > 'username' still works? or are you getting rid of the 'global usernames' > altogether (which is cool too, just want to clarify) ... There will be a GUC param db_user_namespace which will turn it on/off for all access to the cluster _except_ for the super-user. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Wed, Jul 31, 2002 at 05:05:35PM -0400, Bruce Momjian wrote: > OK, I have thought about this. First, a possible solution would be to > have a GUC variable that prepends the dbname to all username > specifications, so the username becomes dbname.username. When you > CREATE USER "test", it actually does CREATE USER "dbname.test". Same > with ALTER/DROP user and lookups in pg_hba.conf and authentication. > Basically it gives us a per-db user namespace. Only the superuser has a > non-db qualified name. What about the following situation: - 3 databases: 'devel', 'staging', and 'production' - one user, 'httpd', which needs access to all 3 databases but doesn't own any of them - I create the 'httpd' user when I'm connected to, say, template1 - I issue a command that changes the httpd user in some way (e.g. drops the user, alters the user, etc.) -- what happens? Also, what happens if I enable the GUC var, create a bunch of different users/databases, and then disable it again? Cheers, Neil -- Neil Conway <neilconway@rogers.com> PGP Key ID: DB3C29FC
Neil Conway wrote: > On Wed, Jul 31, 2002 at 05:05:35PM -0400, Bruce Momjian wrote: > > OK, I have thought about this. First, a possible solution would be to > > have a GUC variable that prepends the dbname to all username > > specifications, so the username becomes dbname.username. When you > > CREATE USER "test", it actually does CREATE USER "dbname.test". Same > > with ALTER/DROP user and lookups in pg_hba.conf and authentication. > > Basically it gives us a per-db user namespace. Only the superuser has a > > non-db qualified name. > > What about the following situation: > > - 3 databases: 'devel', 'staging', and 'production' > > - one user, 'httpd', which needs access to all 3 databases but > doesn't own any of them > > - I create the 'httpd' user when I'm connected to, say, template1 > > - I issue a command that changes the httpd user in some way (e.g. > drops the user, alters the user, etc.) -- what happens? I am going to require the admin to prepend the dbname. GUC controls whether authentication/username map from just the client-supplied username, or the client username prepended with the dbname. > > Also, what happens if I enable the GUC var, create a bunch of different > users/databases, and then disable it again? You swap back and forth between users with prepended dbnames and those withouth. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Wed, 31 Jul 2002, Bruce Momjian wrote: > Marc G. Fournier wrote: > > > Access to nothing. I could actually try to quality by dbname.username, > > > then fall back to just username, but that seems insecure. > > > > No, that's cool ... just questions I thought of ... > > OK. > > > Okay ... hmmm ... just making sure that I understand ... I setup a server, > > when does this dbname.* come into play? Only if I enable password/md5 in > > pg_hba.conf for a specific database? all others would still use a plain > > 'username' still works? or are you getting rid of the 'global usernames' > > altogether (which is cool too, just want to clarify) ... > > There will be a GUC param db_user_namespace which will turn it on/off > for all access to the cluster _except_ for the super-user. Okay ... cluster == database server, or a subset of databases within the server? I know what I think of as a cluster, and somehow I suspect this has to do with the new schema stuff, which means I *really* have to find time to do some catch-up reading ;) need more hours in day, days in week ;(
Marc G. Fournier wrote: > On Wed, 31 Jul 2002, Bruce Momjian wrote: > > > Marc G. Fournier wrote: > > > > Access to nothing. I could actually try to quality by dbname.username, > > > > then fall back to just username, but that seems insecure. > > > > > > No, that's cool ... just questions I thought of ... > > > > OK. > > > > > Okay ... hmmm ... just making sure that I understand ... I setup a server, > > > when does this dbname.* come into play? Only if I enable password/md5 in > > > pg_hba.conf for a specific database? all others would still use a plain > > > 'username' still works? or are you getting rid of the 'global usernames' > > > altogether (which is cool too, just want to clarify) ... > > > > There will be a GUC param db_user_namespace which will turn it on/off > > for all access to the cluster _except_ for the super-user. > > Okay ... cluster == database server, or a subset of databases within the > server? I know what I think of as a cluster, and somehow I suspect this > has to do with the new schema stuff, which means I *really* have to find > time to do some catch-up reading ;) need more hours in day, days in week Cluster is db server in this case. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Wed, Jul 31, 2002 at 11:40:43PM -0400, Bruce Momjian wrote: > > Also, what happens if I enable the GUC var, create a bunch of different > > users/databases, and then disable it again? > > You swap back and forth between users with prepended dbnames and those > withouth. And if I've created the user before I enabled the GUC var, how does authentication work? Cheers, Neil -- Neil Conway <neilconway@rogers.com> PGP Key ID: DB3C29FC
Neil Conway wrote: > On Wed, Jul 31, 2002 at 11:40:43PM -0400, Bruce Momjian wrote: > > > Also, what happens if I enable the GUC var, create a bunch of different > > > users/databases, and then disable it again? > > > > You swap back and forth between users with prepended dbnames and those > > withouth. > > And if I've created the user before I enabled the GUC var, how does > authentication work? User creation will not be effected. You have to prepend the dbname yourself. This will _now_ only effect modification of the user name as passed from the client. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Wed, 31 Jul 2002, Bruce Momjian wrote: > Marc G. Fournier wrote: > > On Wed, 31 Jul 2002, Bruce Momjian wrote: > > > > > Marc G. Fournier wrote: > > > > > Access to nothing. I could actually try to quality by dbname.username, > > > > > then fall back to just username, but that seems insecure. > > > > > > > > No, that's cool ... just questions I thought of ... > > > > > > OK. > > > > > > > Okay ... hmmm ... just making sure that I understand ... I setup a server, > > > > when does this dbname.* come into play? Only if I enable password/md5 in > > > > pg_hba.conf for a specific database? all others would still use a plain > > > > 'username' still works? or are you getting rid of the 'global usernames' > > > > altogether (which is cool too, just want to clarify) ... > > > > > > There will be a GUC param db_user_namespace which will turn it on/off > > > for all access to the cluster _except_ for the super-user. > > > > Okay ... cluster == database server, or a subset of databases within the > > server? I know what I think of as a cluster, and somehow I suspect this > > has to do with the new schema stuff, which means I *really* have to find > > time to do some catch-up reading ;) need more hours in day, days in week > > Cluster is db server in this case. 'K, cool, thanks :) Okay, final request .. how hard would it be to pre-pend the current database name if GUC value is on? ie. if I'm in db1 and run CREATE USER, it will add db1. to the username if I hadn't already? Sounds to me it would be simple to do, and it would "fix" the point I made about being able to have a db "owner" account with create user privileges (ie. if I'm in db1 and run CREATE USER db2.bruce, it should reject that unless I've got create database prileges *and* create user) ... Other then that, most elegant solution, IMHO :)
Marc G. Fournier wrote: > Okay, final request .. how hard would it be to pre-pend the current > database name if GUC value is on? ie. if I'm in db1 and run CREATE USER, > it will add db1. to the username if I hadn't already? Sounds to me it > would be simple to do, and it would "fix" the point I made about being > able to have a db "owner" account with create user privileges (ie. if I'm > in db1 and run CREATE USER db2.bruce, it should reject that unless I've > got create database prileges *and* create user) ... OK, let me get the easy part working first. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
OK, I have attached a patch for testing. Sample output is:
$ sql -U guest test
psql: FATAL: user "test.guest" does not exist
$ createuser test.guest
Shall the new user be allowed to create databases? (y/n) n
Shall the new user be allowed to create more new users? (y/n) n
CREATE USER
#$ sql -U guest test
Welcome to psql, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help on internal slash commands
\g or terminate with semicolon to execute query
\q to quit
test=>
The patch is quite small. All it does is prepend the database name to
the user name supplied with the connection request when
db_user_namespace is true.
This is not ready for application. I can find no way from the
postmaster to determine if the user is the super-user and hence bypass
the database prepending. I was going to do that _only_ for the username
who created the installation for initdb. Maybe I have to dump that name
out to a file and read it in from the postmaster. Other ideas?
It also needs documentation.
I am unsure about auto-prepending the dbname for CREATE USER and other
cases. That could get confusing, especially because createuser accesses
template1, and we would have to handle all other username mentions, like
in GRANT. We may be better just leaving it along and telling admins
they have to quality the username in those cases.
---------------------------------------------------------------------------
Marc G. Fournier wrote:
> On Wed, 31 Jul 2002, Bruce Momjian wrote:
>
> > Marc G. Fournier wrote:
> > > On Wed, 31 Jul 2002, Bruce Momjian wrote:
> > >
> > > > Marc G. Fournier wrote:
> > > > > > Access to nothing. I could actually try to quality by dbname.username,
> > > > > > then fall back to just username, but that seems insecure.
> > > > >
> > > > > No, that's cool ... just questions I thought of ...
> > > >
> > > > OK.
> > > >
> > > > > Okay ... hmmm ... just making sure that I understand ... I setup a server,
> > > > > when does this dbname.* come into play? Only if I enable password/md5 in
> > > > > pg_hba.conf for a specific database? all others would still use a plain
> > > > > 'username' still works? or are you getting rid of the 'global usernames'
> > > > > altogether (which is cool too, just want to clarify) ...
> > > >
> > > > There will be a GUC param db_user_namespace which will turn it on/off
> > > > for all access to the cluster _except_ for the super-user.
> > >
> > > Okay ... cluster == database server, or a subset of databases within the
> > > server? I know what I think of as a cluster, and somehow I suspect this
> > > has to do with the new schema stuff, which means I *really* have to find
> > > time to do some catch-up reading ;) need more hours in day, days in week
> >
> > Cluster is db server in this case.
>
> 'K, cool, thanks :)
>
> Okay, final request .. how hard would it be to pre-pend the current
> database name if GUC value is on? ie. if I'm in db1 and run CREATE USER,
> it will add db1. to the username if I hadn't already? Sounds to me it
> would be simple to do, and it would "fix" the point I made about being
> able to have a db "owner" account with create user privileges (ie. if I'm
> in db1 and run CREATE USER db2.bruce, it should reject that unless I've
> got create database prileges *and* create user) ...
>
> Other then that, most elegant solution, IMHO :)
>
>
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Index: src/backend/libpq/auth.c
===================================================================
RCS file: /cvsroot/pgsql/src/backend/libpq/auth.c,v
retrieving revision 1.82
diff -c -r1.82 auth.c
*** src/backend/libpq/auth.c 20 Jun 2002 20:29:28 -0000 1.82
--- src/backend/libpq/auth.c 1 Aug 2002 05:13:35 -0000
***************
*** 117,123 ****
version, PG_KRB4_VERSION);
return STATUS_ERROR;
}
! if (strncmp(port->user, auth_data.pname, SM_USER) != 0)
{
elog(LOG, "pg_krb4_recvauth: name \"%s\" != \"%s\"",
port->user, auth_data.pname);
--- 117,123 ----
version, PG_KRB4_VERSION);
return STATUS_ERROR;
}
! if (strncmp(port->user, auth_data.pname, SM_DATABASE_USER) != 0)
{
elog(LOG, "pg_krb4_recvauth: name \"%s\" != \"%s\"",
port->user, auth_data.pname);
***************
*** 290,296 ****
}
kusername = pg_an_to_ln(kusername);
! if (strncmp(port->user, kusername, SM_USER))
{
elog(LOG, "pg_krb5_recvauth: user name \"%s\" != krb5 name \"%s\"",
port->user, kusername);
--- 290,296 ----
}
kusername = pg_an_to_ln(kusername);
! if (strncmp(port->user, kusername, SM_DATABASE_USER))
{
elog(LOG, "pg_krb5_recvauth: user name \"%s\" != krb5 name \"%s\"",
port->user, kusername);
Index: src/backend/postmaster/postmaster.c
===================================================================
RCS file: /cvsroot/pgsql/src/backend/postmaster/postmaster.c,v
retrieving revision 1.281
diff -c -r1.281 postmaster.c
*** src/backend/postmaster/postmaster.c 13 Jul 2002 01:02:14 -0000 1.281
--- src/backend/postmaster/postmaster.c 1 Aug 2002 05:13:37 -0000
***************
*** 192,197 ****
--- 192,199 ----
bool HostnameLookup; /* for ps display */
bool ShowPortNumber;
bool Log_connections = false;
+ bool Db_user_namespace = false;
+
/* Startup/shutdown state */
static pid_t StartupPID = 0,
***************
*** 1156,1161 ****
--- 1158,1173 ----
/* Check a user name was given. */
if (port->user[0] == '\0')
elog(FATAL, "no PostgreSQL user name specified in startup packet");
+
+ /* Prefix database name for per-db user namespace */
+ /* XXX look up super-user name from postmaster */
+ if (Db_user_namespace && strcmp(port->user, "postgres"))
+ {
+ char hold_user[SM_DATABASE_USER];
+ snprintf(hold_user, SM_DATABASE_USER, "%s.%s", port->database,
+ port->user);
+ strcpy(port->user, hold_user);
+ }
/*
* If we're going to reject the connection due to database state, say
Index: src/backend/utils/misc/guc.c
===================================================================
RCS file: /cvsroot/pgsql/src/backend/utils/misc/guc.c,v
retrieving revision 1.76
diff -c -r1.76 guc.c
*** src/backend/utils/misc/guc.c 30 Jul 2002 16:20:03 -0000 1.76
--- src/backend/utils/misc/guc.c 1 Aug 2002 05:13:40 -0000
***************
*** 481,486 ****
--- 481,490 ----
{ "transform_null_equals", PGC_USERSET }, &Transform_null_equals,
false, NULL, NULL
},
+ {
+ { "db_user_namespace", PGC_SIGHUP }, &Db_user_namespace,
+ false, NULL, NULL
+ },
{
{ NULL, 0 }, NULL, false, NULL, NULL
Index: src/backend/utils/misc/postgresql.conf.sample
===================================================================
RCS file: /cvsroot/pgsql/src/backend/utils/misc/postgresql.conf.sample,v
retrieving revision 1.42
diff -c -r1.42 postgresql.conf.sample
*** src/backend/utils/misc/postgresql.conf.sample 30 Jul 2002 04:24:54 -0000 1.42
--- src/backend/utils/misc/postgresql.conf.sample 1 Aug 2002 05:13:40 -0000
***************
*** 112,118 ****
#
# Message display
#
-
#server_min_messages = notice # Values, in order of decreasing detail:
# debug5, debug4, debug3, debug2, debug1,
# info, notice, warning, error, log, fatal,
--- 112,117 ----
***************
*** 200,202 ****
--- 199,202 ----
#sql_inheritance = true
#transform_null_equals = false
#statement_timeout = 0 # 0 is disabled
+ #db_user_namespace = false
Index: src/include/libpq/libpq-be.h
===================================================================
RCS file: /cvsroot/pgsql/src/include/libpq/libpq-be.h,v
retrieving revision 1.32
diff -c -r1.32 libpq-be.h
*** src/include/libpq/libpq-be.h 20 Jun 2002 20:29:49 -0000 1.32
--- src/include/libpq/libpq-be.h 1 Aug 2002 05:13:40 -0000
***************
*** 59,65 ****
ProtocolVersion proto;
char database[SM_DATABASE + 1];
! char user[SM_USER + 1];
char options[SM_OPTIONS + 1];
char tty[SM_TTY + 1];
char auth_arg[MAX_AUTH_ARG];
--- 59,65 ----
ProtocolVersion proto;
char database[SM_DATABASE + 1];
! char user[SM_DATABASE_USER + 1];
char options[SM_OPTIONS + 1];
char tty[SM_TTY + 1];
char auth_arg[MAX_AUTH_ARG];
***************
*** 72,78 ****
SSL *ssl;
X509 *peer;
char peer_dn[128 + 1];
! char peer_cn[SM_USER + 1];
unsigned long count;
#endif
} Port;
--- 72,78 ----
SSL *ssl;
X509 *peer;
char peer_dn[128 + 1];
! char peer_cn[SM_DATABASE_USER + 1];
unsigned long count;
#endif
} Port;
Index: src/include/libpq/pqcomm.h
===================================================================
RCS file: /cvsroot/pgsql/src/include/libpq/pqcomm.h,v
retrieving revision 1.64
diff -c -r1.64 pqcomm.h
*** src/include/libpq/pqcomm.h 20 Jun 2002 20:29:49 -0000 1.64
--- src/include/libpq/pqcomm.h 1 Aug 2002 05:13:40 -0000
***************
*** 114,119 ****
--- 114,121 ----
#define SM_DATABASE 64
/* SM_USER should be the same size as the others. bjm 2002-06-02 */
#define SM_USER 32
+ /* We prepend database name if db_user_namespace true. */
+ #define SM_DATABASE_USER (SM_DATABASE+SM_USER)
#define SM_OPTIONS 64
#define SM_UNUSED 64
#define SM_TTY 64
***************
*** 124,135 ****
--- 126,139 ----
{
ProtocolVersion protoVersion; /* Protocol version */
char database[SM_DATABASE]; /* Database name */
+ /* Db_user_namespace prepends dbname */
char user[SM_USER]; /* User name */
char options[SM_OPTIONS]; /* Optional additional args */
char unused[SM_UNUSED]; /* Unused */
char tty[SM_TTY]; /* Tty for debug output */
} StartupPacket;
+ extern bool Db_user_namespace;
/* These are the authentication requests sent by the backend. */
> > * libpqxx is not integrated into build process nor docs. It should
> > be integrated or reversed out before beta.
> I've requestsed that Jeorgen(sp?) move this over to GBorg ... its
> something that can, and should be, built seperately from the base
> distribution, along with at least a dozen other things we have bloating
> the distribution now :( but at least that one hasn't been integrated yet
> ...
Actually, I'm not sure we should target one particular feature to be
left out, unless we have folks who are willing to do the planning,
design, and implementation of a "sliced and diced PostgreSQL" in a
consistant and solid way.
Until we have folks who are excited enough about it to plan it out and
do the work, piecemeal rejection of components is not leading to a more
solid product.
The developers have made the commitment to have consistant and
functional builds across all packages in the main distro. We have no
mechanisms to do the same if the sources are coming from a bunch of
different areas.
Frankly, a 9MB tarball is not in the bloat category in my book. Ask me
about the CORBA package I use that takes 3.5GB to build!!
- Thomas
Thomas Lockhart <lockhart@fourpalms.org> writes:
> Until we have folks who are excited enough about it to plan it out and
> do the work, piecemeal rejection of components is not leading to a more
> solid product.
I'm lukewarm about whether to actually do the split or not ... but for
sure I agree with Thomas' point here. We need a plan and careful
implementation, or a split-up will just make life worse.
Stuff that is in the tree tends to get maintained in passing. For
example, I've got some changes to contrib/dblink/ in my in-progress
version of Chris' DROP COLUMN patch, because a grep for references
to rel->rd_att turned it up. If dblink weren't in our CVS it'd have
been broken by DROP COLUMN, and who knows whether we'd catch that
during beta? I realize that Marc wasn't proposing splitting off any
server-side code, but I still want to tread carefully about breaking
up the codebase.
regards, tom lane
On Thu, 1 Aug 2002, Tom Lane wrote: > Thomas Lockhart <lockhart@fourpalms.org> writes: > > Until we have folks who are excited enough about it to plan it out and > > do the work, piecemeal rejection of components is not leading to a more > > solid product. > > I'm lukewarm about whether to actually do the split or not ... but for > sure I agree with Thomas' point here. We need a plan and careful > implementation, or a split-up will just make life worse. > > Stuff that is in the tree tends to get maintained in passing. For > example, I've got some changes to contrib/dblink/ in my in-progress > version of Chris' DROP COLUMN patch, because a grep for references > to rel->rd_att turned it up. If dblink weren't in our CVS it'd have > been broken by DROP COLUMN, and who knows whether we'd catch that > during beta? I realize that Marc wasn't proposing splitting off any > server-side code, but I still want to tread carefully about breaking > up the codebase. Okay, well, the way I'm working it through right now, I'm doing it in such a way that unless you go mucking in the repository directly, it will be transparent to the coders, as well as to the distribution as a whole ... In fact, based on a comment that Thomas made in another email, I'll even fix up the whole 'cvs checkout pgsql' thing so that that goes back to its previous incarnation of pulling everything, instead of needing to do pgsql-all ... So, from the 'client side', y'all will still see "everything as one big package", while from the 'server side', I'll have the seperate modules taht can be packaged independently ... Next, unless Peter knows how to do it already, I've gotta learn to make configure more intelligent, so that for all intents, the "pieces" look like one package when building, not just when coding ...
On Thu, 2002-08-01 at 02:05, Bruce Momjian wrote: > Marc G. Fournier wrote: > > On Wed, 31 Jul 2002, Neil Conway wrote: > > > > > On Wed, Jul 31, 2002 at 02:01:43AM -0300, Marc G. Fournier wrote: > > > > add in 'fix pg_hba.conf / password issues' to that too :) > > > > > > I doubt that will make 7.3 -- the proposals I've seen on this topic > > > require some reasonably complex additions to the authentication > > > system. We also still need to hash out which design we're going > > > to implement. Given that it's pretty esoteric, I'd prefer this > > > wait for 7.4 > > > > Then, the current changes *should* be removed, as we have no idea how many > > sites out there we are going to break without that functionality ... I > > know I personally have 200+ servers that will all break as soon as I move > > to v7.3 with it as is :( > > OK, I have thought about this. First, a possible solution would be to > have a GUC variable that prepends the dbname to all username > specifications, so the username becomes dbname.username. When I first read Marc's post about this I also thought that the users were partitioned by database, but further reading revealed that tis was not the case - actually they were partitioned by _a_group_of_databases_, as each of his virtual hosts accesses on _at_least_ one but possibly more databases using the same user (bruce ;). So we would need some sort of database groups that share the same users. We have to do something like this: real_user_name = mk_real_user_name(username,dbname) which uses some mapping table to find the real user that is trying to connect to the database. This name mangling should be done at connect time and kept out of database, where each users name should always be fully resolved (bob@accounting.acme.com). This may require raising the length of NAME type to be backwards compatible. Or we migth just add USEDOMAIN column to uniquely identify the user. so the above user would still have usename=bob but also usedomain="accounting.acme.com". ----------- Hannu
On Thu, 2002-08-01 at 06:48, Marc G. Fournier wrote: > On Wed, 31 Jul 2002, Bruce Momjian wrote: > > > One idea I had was to look for a colon in the username, and if I see > > one, I assume everything after the colon is a password. Would that work > > for you? > > That would definitely work ... but I *really* like your GUC idea ... it > would allow ppl to change passwords using simple SQL statements remotely, > which the "old" password stuff didn't allow for ... I think that the users domain should be kept separate from username if at all possible. This is how all modern authentication systems work. ------------- Hannu
> -----Original Message----- > From: Iavor Raytchev [mailto:iavor.raytchev@verysmall.org] > Sent: 31 July 2002 22:12 > To: pgsql-hackers > Cc: pgaccess - developers > Subject: Re: [HACKERS] Open 7.3 items > > > > > > psql is very definitely not ready, nor is pgaccess. > > I could not really trace who said this. > > To my understanding nobody is currently testing how pgaccess > is dealing with 7.3 Am I wrong? If my experience with pgAdmin is anything to go on then you've got a *huge* amount of work to do for 7.3 if you haven't done anything yet. Regards, Dave.
Bruce Momjian dijo: > Here are the open items for 7.3. We have one more month to address them > before beta. > CLUSTER - ready? I'm just back. I'll have a look at the problem with the patch and resubmit. -- Alvaro Herrera (<alvherre[a]atentus.com>) "Es filosofo el que disfruta con los enigmas" (G. Coli)
> > > NAMEDATALEN - disk/performance penalty for increase, 64, 128? > > > FUNC_MAX_ARGS - disk/performance penalty for increase, 24, 32? > > > > At the moment I don't see a lot of solid evidence that increasing > > NAMEDATALEN has any performance penalty. Someone reported about > > a 10% slowdown on pgbench with NAMEDATALEN=128 ... but Neil Conway > > tried to reproduce the result, and got about a 10% *speedup*. > > Personally I think 10% is well within the noise spectrum for > > pgbench, and so it's difficult to claim that we have established > > any performance difference at all. I have not tried to measure > > FUNC_MAX_ARGS differences. > > Yes, we need someone to benchmark both the NAMEDATALEN and FUNC_MAX_ARGS > to prove we are not causing performance problems. I think a valid NAMEDATALEN benchmark would need to use a lot of tables, like 1000-6000 with 10-100 columns each. The last bench was iirc done with pgbench that only uses a few tables. (The name type is fixed length) Andreas
Le Mercredi 31 Juillet 2002 05:50, Bruce Momjian a écrit : > Here are the open items for 7.3. We have one more month to address them > before beta. Is CREATE OR REPLACE VIEW on the list?
"Marc G. Fournier" <scrappy@hub.org> writes:
>> I realize that Marc wasn't proposing splitting off any
>> server-side code, but I still want to tread carefully about breaking
>> up the codebase.
> Okay, well, the way I'm working it through right now, I'm doing it in such
> a way that unless you go mucking in the repository directly, it will be
> transparent to the coders, as well as to the distribution as a whole ...
> In fact, based on a comment that Thomas made in another email, I'll even
> fix up the whole 'cvs checkout pgsql' thing so that that goes back to its
> previous incarnation of pulling everything, instead of needing to do
> pgsql-all ...
Okay, that works for me --- that makes it just a packaging issue, and
not something that will hide stuff from people who want to look through
the whole tree.
regards, tom lane
On Thu, 1 Aug 2002, Tom Lane wrote: > "Marc G. Fournier" <scrappy@hub.org> writes: > >> I realize that Marc wasn't proposing splitting off any > >> server-side code, but I still want to tread carefully about breaking > >> up the codebase. > > > Okay, well, the way I'm working it through right now, I'm doing it in such > > a way that unless you go mucking in the repository directly, it will be > > transparent to the coders, as well as to the distribution as a whole ... > > > In fact, based on a comment that Thomas made in another email, I'll even > > fix up the whole 'cvs checkout pgsql' thing so that that goes back to its > > previous incarnation of pulling everything, instead of needing to do > > pgsql-all ... > > Okay, that works for me --- that makes it just a packaging issue, and > not something that will hide stuff from people who want to look through > the whole tree. Actually, it makes it a 'storage' issue on the CVS server itself, but makes creating various packages easier ... I've pop'd off an email to the libpqxx configure guys to get their standalone configure issues fixed (try running autogen.sh), after which I want to look into 'calling' the standalone configure from the global one if --enable-libpqxx is called (which we can later default to 'on' if that should become the default) ...
Hannu Krosing <hannu@tm.ee> writes:
> This name mangling should be done at connect time and kept out of
> database, where each users name should always be fully resolved
> (bob@accounting.acme.com).
I really like Hannu's approach to this. It seems to solve Marc's
problem with a very simple, easily understood, easily implemented
feature. All we need is a postmaster configuration parameter that
(when TRUE) causes the postmaster to convert the passed username
into 'username@databasename' before looking it up in pg_shadow.
(Actually, what I'd prefer it do is try first for username, and
then username@databasename if plain username isn't found.)
With this approach, we have an underlying mechanism that supports
installation-wide usernames, same as before, but with the flip of
a switch you can configure the system to support per-database
usernames. It's not fancy, maybe, but it will get the job done
with an appropriate amount of effort.
We've had several proposals in this thread for complicated extensions
to the user naming mechanism. I think that's overdesigning the feature,
because we have *no* examples of real-world need for such things except
for Marc's situation. Let's keep it simple until we see real use cases
that can drive the design of something fancy.
> This may require raising the length of NAME type to be backwards
> compatible.
Right, but we're planning to do that anyway.
regards, tom lane
Jean-Michel POURE wrote: > Le Mercredi 31 Juillet 2002 05:50, Bruce Momjian a ?crit : > > Here are the open items for 7.3. We have one more month to address them > > before beta. > > Is CREATE OR REPLACE VIEW on the list? No. It can still be done, but no one is working on it. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Wednesday 31 July 2002 04:56 pm, Bruce Momjian wrote: > Thomas Lockhart wrote: >> Tom Lane wrote: > > > I agree that if we could quickly come to a resolution about how this > > > ought to work, there's plenty of time to go off and implement it. > > afaict someone else volunteered to do the work. There is no lack of > > consensus that this is a useful feature, at least among those who take > > responsibility to package PostgreSQL for particular platforms. How about > > letting them specify the requirements and if an acceptable solution > > emerges soon, we'll have it for 7.3... > Added to open items: > allow specification of configuration files in a different directory Thanks Bruce. I am going to review the previous thread and attempt to distill what can be done. I will then post a summary of what I found, with potential commentary. If a consensus is reached, I'd like to see the feature in 7.3. Peter had mentioned it as well; might want to see if he has done anything as yet with it. That being said, a patch exists for 7.2beta to effect a version of this change. I will also review this patch as I can and see what will be required to make this work in CURRENT. IMO, the key is that if the switch is not specified the current behavior is default. If specified, it will do its thing. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Tom Lane wrote: > Hannu Krosing <hannu@tm.ee> writes: > > This name mangling should be done at connect time and kept out of > > database, where each users name should always be fully resolved > > (bob@accounting.acme.com). > > I really like Hannu's approach to this. It seems to solve Marc's > problem with a very simple, easily understood, easily implemented > feature. All we need is a postmaster configuration parameter that > (when TRUE) causes the postmaster to convert the passed username > into 'username@databasename' before looking it up in pg_shadow. Yes, that is how the patch I submitted last night does it. > (Actually, what I'd prefer it do is try first for username, and > then username@databasename if plain username isn't found.) Yes, that would be very easy to do _except_ for pg_hba.conf which does a first-match for username. We could get into trouble there by trying two versions of the same name. Comments? > With this approach, we have an underlying mechanism that supports > installation-wide usernames, same as before, but with the flip of > a switch you can configure the system to support per-database > usernames. It's not fancy, maybe, but it will get the job done > with an appropriate amount of effort. > > We've had several proposals in this thread for complicated extensions > to the user naming mechanism. I think that's overdesigning the feature, > because we have *no* examples of real-world need for such things except > for Marc's situation. Let's keep it simple until we see real use cases > that can drive the design of something fancy. Agreed. > > > This may require raising the length of NAME type to be backwards > > compatible. > > Right, but we're planning to do that anyway. Yes, but that requires a protocol change, which we don't want to do for 7.3. My fix is to just extend the username on the server side and append the dbname if the switch is on. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Marc G. Fournier wrote: > So, from the 'client side', y'all will still see "everything as one big > package", while from the 'server side', I'll have the seperate modules > taht can be packaged independently ... Marc, how are you dealing with libpq's access to the server include files? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Thu, 2002-08-01 at 16:17, Tom Lane wrote: > Hannu Krosing <hannu@tm.ee> writes: > > This name mangling should be done at connect time and kept out of > > database, where each users name should always be fully resolved > > (bob@accounting.acme.com). > > I really like Hannu's approach to this. It seems to solve Marc's > problem with a very simple, easily understood, easily implemented > feature. All we need is a postmaster configuration parameter that > (when TRUE) causes the postmaster to convert the passed username > into 'username@databasename' before looking it up in pg_shadow. > > (Actually, what I'd prefer it do is try first for username, and > then username@databasename if plain username isn't found.) This should not really be @databasename, but rather a @domainname as Mark does in fact want to use the same user from some virtual host (==domain) for more than one database sometimes. Using databasename as a domainname is just the quickest way to resolve the domainname if no more info about it is given. Thinking of the @xxx part as a domainname and not tying it to databasename would be beneficial in case we later want to use other kinds of domains (like NT, DNS/mail, YP or Kerberos domains for example) If need arises we could later split out the @xxx part to "usedomain" field and perhaps also add "usedomainkind" field in order to manage that info in databse instead of pg_hba.conf. ----------------- Hannu
On Thu, 1 Aug 2002, Bruce Momjian wrote: > Marc G. Fournier wrote: > > So, from the 'client side', y'all will still see "everything as one big > > package", while from the 'server side', I'll have the seperate modules > > taht can be packaged independently ... > > Marc, how are you dealing with libpq's access to the server include > files? I haven't touched libpq yet ... I'm talking with the libpqxx guys right now concerning getting the standalone libpqxx to work, and will be working on figuring out how to get the 'master configure' to make use of the standalone configure once that is fixed ... I want to get one module to work cleanly before looking at any others ...
Marc G. Fournier wrote: > On Thu, 1 Aug 2002, Bruce Momjian wrote: > > > Marc G. Fournier wrote: > > > So, from the 'client side', y'all will still see "everything as one big > > > package", while from the 'server side', I'll have the seperate modules > > > taht can be packaged independently ... > > > > Marc, how are you dealing with libpq's access to the server include > > files? > > I haven't touched libpq yet ... I'm talking with the libpqxx guys right > now concerning getting the standalone libpqxx to work, and will be working > on figuring out how to get the 'master configure' to make use of the > standalone configure once that is fixed ... I want to get one module to > work cleanly before looking at any others ... But isn't libpq++ just going to be part of interfaces? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
I have discussed the idea of contributing our Win32 work to the PostgreSQL project with management. We have also converted all of the utilities (initdb, psql, pg_dump, pg_restore, pg_id, pg_passwd, etc.) Management is (rightfully) concerned about recouping the many thousands of dollars invested in the Win32 conversion. I pointed out that future versions would contain our enhancements and therefore benefit us directly. I pointed out that maintenance is 80% of the cost of a software system and a world-wide team of good programmers would be maintaining the code for all to benefit. And last but not least, good computer Kharma. ;-) They will have to cogitate over it a bit, I think. If they agree, I will make a file with our source tree available on an ftp site. > -----Original Message----- > From: Bruce Momjian [mailto:pgman@candle.pha.pa.us] > Sent: Wednesday, July 31, 2002 1:48 PM > To: Dann Corbit > Cc: Tom Lane; PostgreSQL-development > Subject: Re: [HACKERS] Open 7.3 items > > > > If you can contribute it, I think it would be valuable to the > two other > Win32 projects that are working on porting the 7.3 code to Win32. > > I don't think they will have any code ready for 7.3 but they > may have a > few pieces they want to get in to make their 7.3 patching job easier, > like renaming macros or variables or something. > > > -------------------------------------------------------------- > ------------- > > Dann Corbit wrote: > > > -----Original Message----- > > > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > > > Sent: Tuesday, July 30, 2002 9:50 PM > > > To: Bruce Momjian > > > Cc: PostgreSQL-development > > > Subject: Re: [HACKERS] Open 7.3 items > > [snip] > > > > > > Win32 - timefame? > > > > I may be able to contribute the Win32 stuff we have done here. (Not > > sure of it, but they do seem more open to the idea now). > It's only for > > 7.1.3, and so I am not sure how helpful it would be. There > is also a > > bunch of stuff that looks like this in the code: > > > > #ifdef ICKY_WIN32_KLUDGE > > /* Bletcherous hack to make it work in Win32 goes here... */ > > #else > > /* Normal code goes here... */ > > #endif > > > > Let me know if you are interested. > > > > ---------------------------(end of > broadcast)--------------------------- > > TIP 3: if posting/reading through Usenet, please send an appropriate > > subscribe-nomail command to majordomo@postgresql.org so that your > > message can get through to the mailing list cleanly > > > > -- > Bruce Momjian | http://candle.pha.pa.us > pgman@candle.pha.pa.us | (610) 853-3000 > + If your life is a hard drive, | 830 Blythe Avenue > + Christ can be your backup. | Drexel Hill, > Pennsylvania 19026 >
On Thu, 1 Aug 2002, Dann Corbit wrote: > I have discussed the idea of contributing our Win32 work to the > PostgreSQL project with management. > > We have also converted all of the utilities (initdb, psql, pg_dump, > pg_restore, pg_id, pg_passwd, etc.) > > Management is (rightfully) concerned about recouping the many thousands > of dollars invested in the Win32 conversion. Ask them if they are willing to pay us for the many thousands of dollars we've all invested in giving them something to even convert? *grin*
On Thu, 1 Aug 2002, Bruce Momjian wrote: > Marc G. Fournier wrote: > > On Thu, 1 Aug 2002, Bruce Momjian wrote: > > > > > Marc G. Fournier wrote: > > > > So, from the 'client side', y'all will still see "everything as one big > > > > package", while from the 'server side', I'll have the seperate modules > > > > taht can be packaged independently ... > > > > > > Marc, how are you dealing with libpq's access to the server include > > > files? > > > > I haven't touched libpq yet ... I'm talking with the libpqxx guys right > > now concerning getting the standalone libpqxx to work, and will be working > > on figuring out how to get the 'master configure' to make use of the > > standalone configure once that is fixed ... I want to get one module to > > work cleanly before looking at any others ... > > But isn't libpq++ just going to be part of interfaces? Huh? Each module is to be designed as a standalone project/distribution ... in order to appease those that don't feel that the change is worth it, I'm making, essentially, a 'meta-module' that will pull in the seperate modules into what you've all gotten used to from a development standpoint ... If you checkout pgsql, you will see what you are used to seeing, locally stored in pgsql If you checkout libpqxx, you will just get libpqxx, locally stored in libpqxx If you checkout interfaces, you will get all of the interfaces listed in a 'meta module' consisting of the various interfaces, locally stored in a directory of pgsql/src/interfaces/* For those that are used to cheking out pgsql, continue to do so ... for ppl like Jergeon(sp?), he will checkout libpqxx itself and work on it as if it were a standalone project, but when we package up pgsql, it will get pulled in along with everything else, so that for those that have nothing better to do then download everyhting and the kitchen sink, they can ... At the same time as the distribution is made, a libpqxx.tar.gz will be created, that will be a self-contained source tree for just that, so that those doing ports on the *BSDs or rpms/etc on Linux have pretty much pre-made distros that they don't have to slice and dice (ie. for FreeBSD, you'd do something like go into /usr/ports/database/pgsql-libpqxx, type 'make' and it would automatically go out, download libpq.tar.gz, install it as a dependency and then grab and install the libpqxx file ... if you had already installed libpq previously, for mod_php4, for example, then it would just download and install the libpqxx tar file) ... Unless I break something along the way, as far as you are concerned, nothing has changed ... just keep checking out pgsql as you always have ... but for those of us that pay for our bandwidth by the byte, we'll now be able to download *only* what we require, saving us both time and money ...
Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> (Actually, what I'd prefer it do is try first for username, and
>> then username@databasename if plain username isn't found.)
> Yes, that would be very easy to do _except_ for pg_hba.conf which does a
> first-match for username. We could get into trouble there by trying two
> versions of the same name. Comments?
Hm. I think we'd have to switch around the order of stuff so that we
look at the flat-file copy of pg_shadow first. Then we'd know which
flavor of name we have, and we can proceed with the pg_hba match.
The reason it's worth doing this is that 'postgres', for example, should
be an installation-wide username even when you're using db-local names
for ordinary users.
> This may require raising the length of NAME type to be backwards
> compatible.
>>
>> Right, but we're planning to do that anyway.
> Yes, but that requires a protocol change, which we don't want to do for
> 7.3.
What? We've been discussing raising NAMEDATALEN for months, and no
one's claimed that it qualifies as a protocol version change.
regards, tom lane
Bruce Momjian writes: > OK, I have attached a patch for testing. Sample output is: > > $ sql -U guest test > psql: FATAL: user "test.guest" does not exist > $ createuser test.guest I will object to any scheme that makes any characters in the user name magic. Two reasons: First, do it right, make a separate column. Second, several tools use URI syntax to specify data sources. This will break any feature that relies on being able to put special characters into the user name. The right solution to having database-local user names is putting extra information into pg_shadow regarding which database this user applies to. It could be an array or some separate "authentication domain" thing. -- Peter Eisentraut peter_e@gmx.net
Marc G. Fournier writes: > Next, unless Peter knows how to do it already, I've gotta learn to make > configure more intelligent, so that for all intents, the "pieces" look > like one package when building, not just when coding ... It is possible, but it's not going to work. There is a lot of interdependent and shared C code that needs to be put somewhere. The build infrastructure is not ready to handle missing sub- or superdirectories at all. Where is all the documentation going to go? How are the installation instructions going to cope with the fact that no one knows where everything is? This whole things is a worthwhile idea, to some extent, but a lot more planning needs to be done. In the meantime I humbly suggest you look for a better package manager rather than letting it all out on us. -- Peter Eisentraut peter_e@gmx.net
Tom Lane writes: > We've had several proposals in this thread for complicated extensions > to the user naming mechanism. I think that's overdesigning the feature, > because we have *no* examples of real-world need for such things except > for Marc's situation. Let's keep it simple until we see real use cases > that can drive the design of something fancy. I don't buy this argument. The reason we have no examples is that people are happily using the feature and don't have any reason to tell the world about it. -- Peter Eisentraut peter_e@gmx.net
Lamar Owen writes: > > allow specification of configuration files in a different directory > I am going to review the previous thread and attempt to distill what can be > done. I will then post a summary of what I found, with potential commentary. > If a consensus is reached, I'd like to see the feature in 7.3. The end result of the discussion was that no one could come up with a bright idea to secure the configuration files without doing anything bogus during installation. Another issue, which becomes even more problematic if you factor in the WAL file location discussion, is that if we drive the location of the data from the configuration file instead of vice versa, we need to have initdb smart enough to read those files. Finally, I recall that a major reason to have these files in a separate place is to be able to share them. But that won't work because those files contain port numbers, data directory locations, etc. which can't be shared. That needs a better plan than possibly "use command-line options to override". -- Peter Eisentraut peter_e@gmx.net
Marc G. Fournier writes: > I haven't touched libpq yet ... I'm talking with the libpqxx guys right > now concerning getting the standalone libpqxx to work, and will be working > on figuring out how to get the 'master configure' to make use of the > standalone configure once that is fixed ... I want to get one module to > work cleanly before looking at any others ... I fail to understand how this mess is going to achieve anything. If you like, you can assemble or split the modules into trees or tarballs after you have them checked out, or even after you have downloaded and unpacked them. But a source code repository is not a package manager. Moreover, I would really like it if there was *some* discussion before we are presented with done deals. -- Peter Eisentraut peter_e@gmx.net
On Thursday 01 August 2002 04:06 pm, Peter Eisentraut wrote: > Another issue, which becomes even more problematic if you factor in the > WAL file location discussion, is that if we drive the location of the data > from the configuration file instead of vice versa, we need to have initdb > smart enough to read those files. Hmm, I hadn't thought about that -- but I like that idea. Not exclusive of the existing way, either. But alongside it. More thought required. > Finally, I recall that a major reason to have these files in a separate > place is to be able to share them. But that won't work because those > files contain port numbers, data directory locations, etc. which can't be > shared. That needs a better plan than possibly "use command-line options > to override". No, the major reason was to allow the config files to live in a different area than the data files without symlink kludges. The reasons why an admin might want this are manifold. The reason I want it is to simplify multiple postmasters in an RPM installation. You can then blow away the whole PGDATA tree and start from scratch without losing your config files. You had an idea along these lines, and I was quite OK with the majority of it. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > >> (Actually, what I'd prefer it do is try first for username, and > >> then username@databasename if plain username isn't found.) > > > Yes, that would be very easy to do _except_ for pg_hba.conf which does a > > first-match for username. We could get into trouble there by trying two > > versions of the same name. Comments? > > Hm. I think we'd have to switch around the order of stuff so that we > look at the flat-file copy of pg_shadow first. Then we'd know which > flavor of name we have, and we can proceed with the pg_hba match. > > The reason it's worth doing this is that 'postgres', for example, should > be an installation-wide username even when you're using db-local names > for ordinary users. Yes, that's why my code had a special case for 'postgres' or whatever super-user name it was installed with. I think it is cleaner to just read the install username. Also, right now, pg_pwd only contains usernames that have passwords, not all of them. > > This may require raising the length of NAME type to be backwards > > compatible. > >> > >> Right, but we're planning to do that anyway. > > > Yes, but that requires a protocol change, which we don't want to do for > > 7.3. > > What? We've been discussing raising NAMEDATALEN for months, and no > one's claimed that it qualifies as a protocol version change. I thought they were talking about increasing the length of the user NAME that comes of the wire. That is currently 32. I see now he was just talking about NAMEDATALEN. Good thing we are prepending the database name after receiving the name. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Peter Eisentraut wrote: > Bruce Momjian writes: > > > OK, I have attached a patch for testing. Sample output is: > > > > $ sql -U guest test > > psql: FATAL: user "test.guest" does not exist > > $ createuser test.guest > > I will object to any scheme that makes any characters in the user name > magic. Two reasons: First, do it right, make a separate column. > Second, several tools use URI syntax to specify data sources. This will > break any feature that relies on being able to put special characters into > the user name. > > The right solution to having database-local user names is putting extra > information into pg_shadow regarding which database this user applies to. > It could be an array or some separate "authentication domain" thing. OK, if you object, you can say goodbye to this feature for 7.3. I can supply the patch to Marc and anyone else who wants it but I am not inclined nor convinced we need that level of work for this feature. So we end up with nothing. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Peter Eisentraut wrote: > Tom Lane writes: > > > We've had several proposals in this thread for complicated extensions > > to the user naming mechanism. I think that's overdesigning the feature, > > because we have *no* examples of real-world need for such things except > > for Marc's situation. Let's keep it simple until we see real use cases > > that can drive the design of something fancy. > > I don't buy this argument. The reason we have no examples is that people > are happily using the feature and don't have any reason to tell the world > about it. Well, we are going to find out in 7.3 when the secondary password file is no longer supported. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Thu, 1 Aug 2002, Bruce Momjian wrote: > Peter Eisentraut wrote: > > Bruce Momjian writes: > > > > > OK, I have attached a patch for testing. Sample output is: > > > > > > $ sql -U guest test > > > psql: FATAL: user "test.guest" does not exist > > > $ createuser test.guest > > > > I will object to any scheme that makes any characters in the user name > > magic. Two reasons: First, do it right, make a separate column. > > Second, several tools use URI syntax to specify data sources. This will > > break any feature that relies on being able to put special characters into > > the user name. > > > > The right solution to having database-local user names is putting extra > > information into pg_shadow regarding which database this user applies to. > > It could be an array or some separate "authentication domain" thing. > > OK, if you object, you can say goodbye to this feature for 7.3. I can > supply the patch to Marc and anyone else who wants it but I am not > inclined nor convinced we need that level of work for this feature. > > So we end up with nothing. Stupid qustion .. but why can't you just add a 'domain' column to pg_passwd/pg_shadow so that its stored as two fields instead of one? Which I believe is what Pter is/was suggesting ...
Marc G. Fournier wrote: > > > I will object to any scheme that makes any characters in the user name > > > magic. Two reasons: First, do it right, make a separate column. > > > Second, several tools use URI syntax to specify data sources. This will > > > break any feature that relies on being able to put special characters into > > > the user name. > > > > > > The right solution to having database-local user names is putting extra > > > information into pg_shadow regarding which database this user applies to. > > > It could be an array or some separate "authentication domain" thing. > > > > OK, if you object, you can say goodbye to this feature for 7.3. I can > > supply the patch to Marc and anyone else who wants it but I am not > > inclined nor convinced we need that level of work for this feature. > > > > So we end up with nothing. > > Stupid qustion .. but why can't you just add a 'domain' column to > pg_passwd/pg_shadow so that its stored as two fields instead of one? > Which I believe is what Pter is/was suggesting ... Right now, pg_pwd only dumps users with passwords, and as I remember, it is only accessed when the protocol needs to lookup a password. It wasn't designed for anything more advanced. If you want separate columns, you have to dump out everyone, and modify CREATE USER, createuser, ALTER USER, ... to handle those new domain names, and you have to make this API visible to everyone even if they are not using domains. That's where things really get ugly. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian wrote: > Functions Returning Sets - done? The basic capability is done, but a number of supporting capabilities remain. These are the ones I hope to have done for 7.3: - PL/pgSQL table function support: not started, but I may get help with this. - anonymous composite types: patch submitted - stand-alone composite types: proposal submitted - implicit stand-alone composite types on CREATE FUNCTION: proposal submitted - Move show_all_settings() from contrib/tablefunc to the backend and create a system view using the same method as Neil'spg_locks view. Additional refinements (streaming vs tuplestore, rescan pushed from planner to executor, etc) will be 7.4 items. Additionally on my personal TODO for 7.3 are: - modify contrib/dblink to take advantage of table function and new composite type capabilities - submit string manipulation functions discussed with Thomas a few weeks ago --> replace(), to_hex(), extract_tok() Joe
On Wed, Jul 31, 2002 at 02:08:33PM -0300, Marc G. Fournier wrote: > > Who cares? Those that need a C++ interface will know where to find it, > and will report bugs that they have ... why should it be tested on every > platform when we *might* only have those on the Linux platform using it? Well, portability's actually a lot better than that OS-wise. The thing to worry about is compilers. I've got some changes from Clinton James waiting in the wings until libpqxx's status and development home are settled. Those changes will make it compile on the latest version of Visual C++ (and I'll take some changes out again once they're no longer needed for that purpose), and most of it seems to work. > What happens if/when libpqxx becomes the 'old, crufty interface' and > something newer and shinier comes along? Where do we draw the line at > what is in the distribution? For instance, why pgaccess vs a platform > independent version of PgAdmin vs PHPPgAdmin? Hell, IMHO, PHPPgAdmin > would most likely be more useful as more sites out there are running PHP > then likely have TCL installed ... but someone that is using TCL/AolServer > would definitely think otherwise ... Looking at it that way, it seems to me that the proper approach is to cut out all interfaces that don't talk to the backend themselves--e.g. the ones that build on top of libpq, like libpq++ and libpqxx do. Of course my humble but thoroughly biased opinion is that libpq++ be marked "legacy." > By branching out the fat, we make it *easier* for someone to take on > development of it ... would libpqxx ever have been developed if Joergen > could have just worked on libpq++ in the first place, without having to > submit patches? Yes. Now STOP BRUTALIZING MY NAME! ... Phew. I feel better now. What was I saying? Ah, yes. What you say pretty much describes how libpqxx came to be: get a local copy of libpq++, try to fix it on a carte-blanche basis, find nothing salvageable, write from scratch building on libpq++'s experience. That said, I do support the idea of separately administered projects for the reasons you give. Looking at specifics first, the problem I'm stuck with for now is that I can't really work on the thing until this point is decided. Well I could, but not until the doctor lets me get back to it. Which requires, among other things, that it not give me headaches. :-) For the more general case, there's the problem of release management: who's going to be taking care of synchronizing releases? This may require some new infrastructure, such as a mailing list dedicated to the process, or one restricted to subproject maintainers. Or something. Perhaps the unbundling of subprojects justifies that version bump to 8.0 after all... Jeroen (Juliet Echo Romeo Oscar Echo November. Jeroen. No G. Note intricate order of vowels. Phonetic spelling in English would be Yeroon. Try to roll the "r" a little.)
On Fri, 2 Aug 2002, jtv wrote: > Looking at it that way, it seems to me that the proper approach is to > cut out all interfaces that don't talk to the backend themselves--e.g. > the ones that build on top of libpq, like libpq++ and libpqxx do. This is what my opinion is ... what I'm setting up right now with CVS is meant to be a middle ground ... > Of course my humble but thoroughly biased opinion is that libpq++ be > marked "legacy." No doubt, but, if we didn't "push" one interface over another, then it would be up to the end-users themselves to decide which one to install ... > > By branching out the fat, we make it *easier* for someone to take on > > development of it ... would libpqxx ever have been developed if Joergen > > could have just worked on libpq++ in the first place, without having to > > submit patches? > > Yes. Okay, then let's word it another way ... if libpq++ *wasn't* in the repository and part of the distribution, would you have a) started working on it sooner? b) would you have made it public earlier? c) would ppl have started to use it and stop'd using libpq++? Basically, with libpq++ in the distribution, we are endorsing its use, so if we didn't put libpqxx into the repository, would ppl switch from the 'endorsed' to the 'unendorsed' version? By having libpq++ in the repository, we are adding weight to it that it wouldn't have if it were outside of the repository, making it more difficult for 'alternatives' to pop in ... > For the more general case, there's the problem of release management: who's > going to be taking care of synchronizing releases? This may require some > new infrastructure, such as a mailing list dedicated to the process, or one > restricted to subproject maintainers. Or something. Well, for now, I'd say keep the status quo of just using -hackers ...
On Thu, 2002-08-01 at 20:41, Dann Corbit wrote: > I have discussed the idea of contributing our Win32 work to the > PostgreSQL project with management. > > We have also converted all of the utilities (initdb, psql, pg_dump, > pg_restore, pg_id, pg_passwd, etc.) > > Management is (rightfully) concerned about recouping the many thousands > of dollars invested in the Win32 conversion. > > I pointed out that future versions would contain our enhancements and > therefore benefit us directly. Also, having some other win32 port as an official version would make it even harder for them to recoup their money. Saying that your verison is the base of the "official" is always a good selling point. They can advance (a little) their recouping only in case when not contributing delays the native win32 port by some significant amount of time and at the same time postgreSQL somehow magically becomes popular among Win32 folks. I doubt that the last two can happen simultaneously. > I pointed out that maintenance is 80% of the cost of a software system > and a world-wide team of good programmers would be maintaining the code > for all to benefit. It also gives your customers a guarantee for the case you company goes belly-up, which /could/ also be a selling point ;) > And last but not least, good computer Kharma. > ;-) You could also mention the argument of "having bigger pies vs. having a bigger slice of a tiny pie" ;) --------------- Hannu
On Thu, 2002-08-01 at 23:20, Bruce Momjian wrote: > Marc G. Fournier wrote: > > > > I will object to any scheme that makes any characters in the user name > > > > magic. Two reasons: First, do it right, make a separate column. > > > > Second, several tools use URI syntax to specify data sources. This will > > > > break any feature that relies on being able to put special characters into > > > > the user name. This should be settable using a GUC variable (in postgresql.conf as it makes no sense once you are connected). > > > > The right solution to having database-local user names is putting extra > > > > information into pg_shadow regarding which database this user applies to. > > > > It could be an array or some separate "authentication domain" thing. > > > > > > OK, if you object, you can say goodbye to this feature for 7.3. I can > > > supply the patch to Marc and anyone else who wants it but I am not > > > inclined nor convinced we need that level of work for this feature. > > > > > > So we end up with nothing. > > > > Stupid qustion .. but why can't you just add a 'domain' column to > > pg_passwd/pg_shadow so that its stored as two fields instead of one? > > Which I believe is what Pter is/was suggesting ... > > Right now, pg_pwd only dumps users with passwords, and as I remember, it > is only accessed when the protocol needs to lookup a password. It > wasn't designed for anything more advanced. If you want separate > columns, you have to dump out everyone, and modify CREATE USER, > createuser, ALTER USER, ... to handle those new domain names, and you > have to make this API visible to everyone even if they are not using > domains. That's where things really get ugly. Actually _not_ modifying the commands (and thus leaving the pg_shadow.usedomain column empty) will give us exactly the old behaviour. For advanced uses it should be an acceptable interim solution to have the superuser update the pg_shadow manually. But if noone has time to work on it more than just mangling usernames at connect time, that should also be ok for 7.3. We just have to document it and warn of a new change to real domain users in 7.4 (or later). -------------- Hannu
Neil Conway said: >> FUNC_MAX_ARGS - disk/performance penalty for increase, 24, 32? > >Until someone takes the time to determine what the performance >implications of this change will be, I don't think we should >change this. Given that no one has done any testing, I'm not >convinced that there's a lot of demand for this anyway. There's a huge demand for this from the folks involved with OpenACS. Already many of the functions have run up against the 16 column limit. Overloading is an ugly cludge for some functions which have 'default' args, but it's not a complete solution. Not that it has proven to be slower, but if it were but the difference was small, I'd say that forcing a recomplile to eek out a little extra performance is better than forcing it to make code work in the first place. 32 args, please! Cheers.
On Thu, Aug 01, 2002 at 09:07:46PM -0300, Marc G. Fournier wrote: > > > Of course my humble but thoroughly biased opinion is that libpq++ be > > marked "legacy." > > No doubt, but, if we didn't "push" one interface over another, then it > would be up to the end-users themselves to decide which one to install ... In theory, yes. In this case, however, I see two arguments for making the distinction anyway: 1. Some people won't want to go to the trouble of comparing available interfaces, so they may default to libpq++ because it's what they found first, or because they find mentions of it as the official C++ interface. I think it would be a shame to have new users default to libpq++ "by accident." I think many users would prefer to rely on the PostgreSQL team's judgment--as they do by choosing Postgres in the first place. 2. I get the impression that libpq++ sort of got stuck before it was completed. For the time being libpqxx appears to have better maintenance prospects. Users will want to be aware of this before making a choice. > Okay, then let's word it another way ... if libpq++ *wasn't* in the > repository and part of the distribution, would you have a) started working > on it sooner? b) would you have made it public earlier? c) would ppl > have started to use it and stop'd using libpq++? I'm not sure there's much point to going into a single example in detail, but for completeness' sake I'll just answer these: a) Yes. b) No, because in my case I was encouraged by team members' endorsement of first my suggestions for libpq++, and later a full replacement. Without that, and without an active libpq++ maintainer around, libpqxx might never have gotten off the ground. c) I'd like to think so, yes--but exposure would have been harder. > Basically, with libpq++ in the distribution, we are endorsing its use, so > if we didn't put libpqxx into the repository, would ppl switch from the > 'endorsed' to the 'unendorsed' version? > > By having libpq++ in the repository, we are adding weight to it that it > wouldn't have if it were outside of the repository, making it more > difficult for 'alternatives' to pop in ... I definitely agree here. See above. > > For the more general case, there's the problem of release management: who's > > going to be taking care of synchronizing releases? This may require some > > new infrastructure, such as a mailing list dedicated to the process, or one > > restricted to subproject maintainers. Or something. This reminds me of another potential complication: how would unbundling affect the licensing situation? Mixing and matching components is good in many ways, but it could complicate the situation for end-users--who probably like to be able to rely on the team's judgment on this issue as well. I feel compelled at this point to admit that I prefer the GPL. This is a personal preference, which I set aside because I wanted and expected libpqxx to become the standard C++ interface. Had these interfaces not been bundled, I would have had less incentive to conform to Postgres' licensing conditions. I think having a different license would have made everyone's life a little harder. Jeroen (and yes, I'm trying to repair my From: lines!)
On Thu, 2002-08-01 at 00:42, Stephen Deasey wrote: > Neil Conway said: > >> FUNC_MAX_ARGS - disk/performance penalty for increase, 24, 32? > > > >Until someone takes the time to determine what the performance > >implications of this change will be, I don't think we should > >change this. Given that no one has done any testing, I'm not > >convinced that there's a lot of demand for this anyway. > > > There's a huge demand for this from the folks involved with OpenACS. > Already many of the functions have run up against the 16 column limit. > Overloading is an ugly cludge for some functions which have 'default' > args, but it's not a complete solution. > > Not that it has proven to be slower, but if it were but the difference > was small, I'd say that forcing a recomplile to eek out a little extra > performance is better than forcing it to make code work in the first > place. > > 32 args, please! 32 at a bare minimum. Someone needs to dig out what the problem is and make the cost increase with length. > 128 args is easily feasibly given some Oracle systems I've seen -- DB functions as middleware.
Bruce Momjian writes: > OK, if you object, you can say goodbye to this feature for 7.3. I can > supply the patch to Marc and anyone else who wants it but I am not > inclined nor convinced we need that level of work for this feature. The right solution, IMO, is to resurrect the feature we had and think about a fully-featured solution for the next release. Or try to sell the proposed solutions as fully-featured . . . -- Peter Eisentraut peter_e@gmx.net
It had such limited usefulness ('password' only, only crypted-hashed
passwords in the file) that it doesn't make much sense to resurect it.
To directly address your point, I don't think this new feature will be
used enough to add the capability to the user admin commands.
I know you object, so I am going to ask for a vote.
OK, here is the request for vote. Do we want:
1) the old secondary passwords re-added2) the new prefixing of the database name to the username when enabled3) do
nothing
---------------------------------------------------------------------------
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > OK, if you object, you can say goodbye to this feature for 7.3. I can
> > supply the patch to Marc and anyone else who wants it but I am not
> > inclined nor convinced we need that level of work for this feature.
>
> The right solution, IMO, is to resurrect the feature we had and think
> about a fully-featured solution for the next release. Or try to sell the
> proposed solutions as fully-featured . . .
>
> --
> Peter Eisentraut peter_e@gmx.net
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html
>
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
> OK, here is the request for vote. Do we want: > 2) the new prefixing of the database name to the username when enabled I vote 2.
On Tue, 6 Aug 2002, Bruce Momjian wrote:
>
> It had such limited usefulness ('password' only, only crypted-hashed
> passwords in the file) that it doesn't make much sense to resurect it.
It had limited usefulness to you ... but how many sites out there are
going to break when they try to upgraded without it there? I do agree
that it needs to improved / replaced, but without a suitable replacement
in place, the old should be resurrected until such a suitable one is in
place ...
> I know you object, so I am going to ask for a vote.
How can you request a vote of such a limited audience? *Adding*
functionality is easy ... removing functionality with at least a release
for-warning is easy ... removing a feature without any forewarning is akin
to cutting our own throats ...
> OK, here is the request for vote. Do we want:
>
> 1) the old secondary passwords re-added
> 2) the new prefixing of the database name to the username when enabled
> 3) do nothing
If 2 can be done in such a way to be transparent, as well as to allow a
database owner to be able to create users for his/her database, then I
think it would be great ... and would far exceed what we have now ...
If you can't do 2 as a complete solution, which, IMHO, includes a db owner
being able to create db.users for his own database, then my vote is for 1
... if 2 can be done completely, then I vote for 2, as it would definitely
be much more useful ...
Hrmmm ... I was just thinking of another scenario where such a feature
would be great ... educational. The ability to setup a database server,
but to give a professor a database for a course that he could create
'accounts' for each of the students ...
I would personally like to see 2, however, Marc is correct IMHO. I cast
my vote using the qualifiers that Marc laid out below.
Greg
On Tue, 2002-08-06 at 20:24, Marc G. Fournier wrote:
> On Tue, 6 Aug 2002, Bruce Momjian wrote:
>
> >
> > It had such limited usefulness ('password' only, only crypted-hashed
> > passwords in the file) that it doesn't make much sense to resurect it.
>
> It had limited usefulness to you ... but how many sites out there are
> going to break when they try to upgraded without it there? I do agree
> that it needs to improved / replaced, but without a suitable replacement
> in place, the old should be resurrected until such a suitable one is in
> place ...
>
> > I know you object, so I am going to ask for a vote.
>
> How can you request a vote of such a limited audience? *Adding*
> functionality is easy ... removing functionality with at least a release
> for-warning is easy ... removing a feature without any forewarning is akin
> to cutting our own throats ...
>
> > OK, here is the request for vote. Do we want:
> >
> > 1) the old secondary passwords re-added
> > 2) the new prefixing of the database name to the username when enabled
> > 3) do nothing
>
> If 2 can be done in such a way to be transparent, as well as to allow a
> database owner to be able to create users for his/her database, then I
> think it would be great ... and would far exceed what we have now ...
>
> If you can't do 2 as a complete solution, which, IMHO, includes a db owner
> being able to create db.users for his own database, then my vote is for 1
> ... if 2 can be done completely, then I vote for 2, as it would definitely
> be much more useful ...
>
> Hrmmm ... I was just thinking of another scenario where such a feature
> would be great ... educational. The ability to setup a database server,
> but to give a professor a database for a course that he could create
> 'accounts' for each of the students ...
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
> How can you request a vote of such a limited audience? *Adding* > functionality is easy ... removing functionality with at least a release > for-warning is easy ... removing a feature without any forewarning is akin > to cutting our own throats ... Yea, but it was such an ugly feature and I honestly thought no one was using it. In fact, you aren't even using it in the indended way of sharing /etc/passwd. You are using it to implement a different capability that I never even imagined. :-) > > > OK, here is the request for vote. Do we want: > > > > 1) the old secondary passwords re-added > > 2) the new prefixing of the database name to the username when enabled > > 3) do nothing > > If 2 can be done in such a way to be transparent, as well as to allow a > database owner to be able to create users for his/her database, then I > think it would be great ... and would far exceed what we have now ... > > If you can't do 2 as a complete solution, which, IMHO, includes a db owner > being able to create db.users for his own database, then my vote is for 1 > ... if 2 can be done completely, then I vote for 2, as it would definitely > be much more useful ... Well, as it currently stands in the patch, a db owner can create any user they want, including users for just their dbs. However, remember that Once someone can create a user, they can create a superuser, so security for those folks is impossible. The patch does not prevent them from creating user for other databases, if that is what you wanted, but did your previous solution allow this? > > Hrmmm ... I was just thinking of another scenario where such a feature > would be great ... educational. The ability to setup a database server, > but to give a professor a database for a course that he could create > 'accounts' for each of the students ... Yep, with no conflicting names. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Tue, 6 Aug 2002, Bruce Momjian wrote: > > How can you request a vote of such a limited audience? *Adding* > > functionality is easy ... removing functionality with at least a release > > for-warning is easy ... removing a feature without any forewarning is akin > > to cutting our own throats ... > > > Yea, but it was such an ugly feature and I honestly thought no one was > using it. In fact, you aren't even using it in the indended way of > sharing /etc/passwd. You are using it to implement a different > capability that I never even imagined. :-) Can you point me to where this documentation is on its intended use? *raised eyebrow* Just bcause you couldn't imagine it being used the way I am, doesn't mean that wasn't what it was intended for :) > Well, as it currently stands in the patch, a db owner can create any > user they want, including users for just their dbs. However, remember > that Once someone can create a user, they can create a superuser, so > security for those folks is impossible. The patch does not prevent them > from creating user for other databases, if that is what you wanted, but > did your previous solution allow this? But, the patch should ... how hard is it to add code in that says "if connected to db1 *and* have creat user privs, then allow create of db1.<username>"? Personally, from using cyrus-imapd for much much too long, I think what we're looking at is 'realms' ... if 'enable_realms' is enabled in postmaster.conf, then a user creatd wile connetd to db1 shuld have db1 appended automagically ... then again, i do think its "a Bad Thing" to have this enable/disableable, since it will cause some serious confusion ... its kinda like everyone's argument against Thomas' recent patch about XLOG ... what if you forget? it should be an initdb option (--enable-realms) so that its a one-time-only decision when you create the database instance, not something that you can flip on/off ... default would be disabled, to reflect current behaviour (minus the password file) ... or, another option would be 'CREATE DATABASE <DB> WITH REALMS', so that you could have some with, some without ... so, if a DATABASE was creatd with REALMS, a flag would be set in pg_database stating that only those users with db. prefix have access to that database ... then again, another neat thing would be he ability to 'group' databases ... CREATE DATABASE <DB> IN GROUP <dbgroup>, so that users would be named dbgroup.* and would b able to login to any database within that group ... but those are just ideas thrown out ... IMHO, critical for v7.3, if we don't revert the patch, is to have *either* '--enable-realms' to set an instance in that mode, *or* have it on a per database basis ... I think having it as an on/off setting in postmaster.conf is just askng for trouble ...
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> OK, here is the request for vote. Do we want:
> 1) the old secondary passwords re-added
> 2) the new prefixing of the database name to the username when enabled
> 3) do nothing
I vote for 2b), username@database ...
regards, tom lane
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > >>OK, here is the request for vote. Do we want: > > >> 1) the old secondary passwords re-added >> 2) the new prefixing of the database name to the username when enabled >> 3) do nothing > > > I vote for 2b), username@database ... > I like that too -- and it has the added benefit of being similar to Oracle (username@tns_servicename; tns_servicename is really just a pointer to the IP/port of a specific Oracle database). Joe
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> OK, here is the request for vote. Do we want:
>
> 1) the old secondary passwords re-added
> 2) the new prefixing of the database name to the username when enabled
> 3) do nothing
I'd vote #3, for the following reasons:
- The functionality that Marc is worried about (in effect, allowing multiple database users with the same
name)is pretty obscure, and the implementation is even more so. I doubt whether there is *anyone* other than
Marcactually using it (if that's not the case, please speak up).
Given that it was completely undocumented and a pretty clear abuse of the existing code, I don't think
it'sunreasonable for us to break backward compatibility on this issue.
- The old way of doing things is broken, for reasons Bruce has elaborated on. Unless there's a
compellingreason why we *need* this feature in the standard distribution, I'd rather we not go back to
theold way of doing things.
- I'm not perfectly happy with the scheme Bruce suggested as an interim fix (#2). If we're going to
implementthis feature, let's do it properly. In particular, I'm not convinced that this feature is
urgentlyneeded enough to justify a short-term kludge, and I dislike using a GUC variable to toggle
betweentwo quite different authentication processes.
So I'd say leave things as they are. One thing I'd like to see anyway
is a more prominent listing of the client-visible incompatibilities in
the release notes -- I'd be content to add an entry to that list for
the 7.3 release and talk about a more elaborate scheme during the 7.4
development cycle.
Cheers,
Neil
--
Neil Conway <neilconway@rogers.com>
PGP Key ID: DB3C29FC
> -----Original Message-----
> From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
> Sent: 07 August 2002 02:09
> To: Peter Eisentraut
> Cc: Marc G. Fournier; Ron Snyder; Neil Conway; PostgreSQL-development
> Subject: Re: [HACKERS] Open 7.3 items
>
>
>
> It had such limited usefulness ('password' only, only
> crypted-hashed passwords in the file) that it doesn't make
> much sense to resurect it.
>
> To directly address your point, I don't think this new
> feature will be used enough to add the capability to the user
> admin commands.
>
> I know you object, so I am going to ask for a vote.
>
> OK, here is the request for vote. Do we want:
>
> 1) the old secondary passwords re-added
> 2) the new prefixing of the database name to the
> username when enabled
> 3) do nothing
2 please. I have used secondary passwords in the past, but 2 would do
the same job and seems cleaner.
Regards, Dave.
> - The functionality that Marc is worried about (in effect, > allowing multiple database users with the same name) is > pretty obscure, and the implementation is even more so. I > doubt whether there is *anyone* other than Marc actually > using it (if that's not the case, please speak up). I would use database specific users for a similar area -- shared hosting. But, could live with a longer (128 byte) namedatalen to allow a unique user%domain.
Rod Taylor <rbt@zort.ca> writes: > > - The functionality that Marc is worried about (in effect, > > allowing multiple database users with the same name) is > > pretty obscure, and the implementation is even more so. I > > doubt whether there is *anyone* other than Marc actually > > using it (if that's not the case, please speak up). > > I would use database specific users for a similar area -- shared > hosting. I agree that the functionality Marc is looking for is useful -- I'm just saying that I would bet that *no one* is using the current implementation of it in PostgreSQL (i.e. so I don't see the need to keep backward compatibility, or the harm in removing the feature for the next release until a better solution is designed & implemented). > But, could live with a longer (128 byte) namedatalen to allow > a unique user%domain. That seems like a serviceable solution to me -- it seems quite easy to implement this functionality outside the database proper (at least until a proper solution is devised). Keep in mind that the current FE/BE protocol limits database and user names to 64 characters. That's another thing I'd like to fix in 7.4. Cheers, Neil -- Neil Conway <neilconway@rogers.com> PGP Key ID: DB3C29FC
> > But, could live with a longer (128 byte) namedatalen to allow > > a unique user%domain. > > That seems like a serviceable solution to me -- it seems quite easy to > implement this functionality outside the database proper (at least > until a proper solution is devised). Keep in mind that the current > FE/BE protocol limits database and user names to 64 characters. > That's another thing I'd like to fix in 7.4. Aw shoot. 64 characters isn't enough to hold a good chunk of our clients domain names let alone usernames in front. I'm not looking forward to trimming domains either. I hope 7.4 that a protocol change for 7.4 is warranted. Looks like there are a fair number of things in that area.
Neil Conway <nconway@klamath.dyndns.org> writes:
> Keep in mind that the current
> FE/BE protocol limits database and user names to 64 characters.
That seems to be a good reason to combine the two on the postmaster
side, a la Bruce's proposed patch. If the client side does it then
the "user@database" has to all fit in 64 characters.
> That's another thing I'd like to fix in 7.4.
Yup. Do we have a list going of the things we want to fix in the next
protocol change? Offhand I remember
* redesign startup packet to eliminate fixed field widths
* fix COPY protocol to allow resync after errors, support binary data
* less brain-dead protocol for fast-path function calls
* allow NOTIFY to include parameters
* richer ERROR reports (error codes, other stuff)
and I'm sure there's more. None of this stuff seems to be in the TODO
list though.
regards, tom lane
On Tuesday 06 August 2002 09:24 pm, Marc G. Fournier wrote:
> On Tue, 6 Aug 2002, Bruce Momjian wrote:
> > It had such limited usefulness ('password' only, only crypted-hashed
> > passwords in the file) that it doesn't make much sense to resurect it.
> It had limited usefulness to you ... but how many sites out there are
> going to break when they try to upgraded without it there? I do agree
> that it needs to improved / replaced, but without a suitable replacement
> in place, the old should be resurrected until such a suitable one is in
> place ...
While it appears I'll be outvoted on this issue, and even though I agree that
the existing functionality is broken, and even though I am not using the
functionality, I am reminded of the overall policy that we have historically
had about removing even broken features. Fair Warning must be given. If that
policy is going to be changed, then it needs to be applied with equal vigor
to all affected cases.
Even if Marc is the only one using this feature, we should follow established
policy -- that is, after all, what policy is for. To me it seems it is being
yanked gratuitously without fair warning. If every question is answered on a
case-by-case basis like this, we will descend to anarchy, I'm afraid. And,
Bruce, I even agree with your reasons -- I just disagree with the method.
Is it going to cause a major problem for it to remain one release cycle while
someone works on a suitable replacement, with the warning in the release
notes that while this feature is there for backwards compatibility that it
will be yanked at the next release? And I'm not talking about a minor
problem like 'more people will start using it' -- I'm talking 'if it stays we
will be in danger of massive data corruption or exposure' -- of course,
documenting that there is a degree of exposure of data if not set up in an
exacting method, as Marc seems to have done.
Some may say Marc has fair warning now -- but does anyone know for sure that
NO ONE ELSE in the whole world isn't using this feature? Marc is more in the
know than most, granted -- but if he found this use for the feature others
may have as well that we don't even know about.
But if the feature is not going to remain it needs to be prominently
documented as being removed in the release notes.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
Tom Lane <tgl@sss.pgh.pa.us> writes: > Do we have a list going of the things we want to fix in the next > protocol change? Offhand I remember > > * redesign startup packet to eliminate fixed field widths > * fix COPY protocol to allow resync after errors, support binary data > * less brain-dead protocol for fast-path function calls > * allow NOTIFY to include parameters > * richer ERROR reports (error codes, other stuff) Some kind of parameter binding or improved support for prepareable statements would require changes to the FE/BE protocol -- being able to accept parameters without passing them through the parser, for example. Allowing clients to cleanly determine the current transaction state will require FE/BE protocol changes, I think. (Or at least, that's my vague recollection of the discussion on -hackers from a couple months ago). That's all I can think of -- there's probably more stuff... Cheers, Neil -- Neil Conway <neilconway@rogers.com> PGP Key ID: DB3C29FC
Neil Conway <nconway@klamath.dyndns.org> writes:
> Some kind of parameter binding or improved support for prepareable
> statements would require changes to the FE/BE protocol -- being able
> to accept parameters without passing them through the parser, for
> example.
Right. This is nearly the same, perhaps could be made actually the
same, as a fast-path function call.
The existing FPF call mechanism only supports binary data, but I think
it would be useful to allow either binary data or ASCII data in both FPF
and prepared-statement cases. The ASCII path would require invoking a
datatype's conversion function on the backend side, but you'd still get
to skip the SQL statement parsing/planning overhead.
(Wanders away wondering whether COPY might not be made to fit into this
same mold...)
regards, tom lane
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > OK, here is the request for vote. Do we want: > > > 1) the old secondary passwords re-added > > 2) the new prefixing of the database name to the username when enabled > > 3) do nothing > > I vote for 2b), username@database ... Yes, the format was going to be my second vote, dbname.username or username@dbname. Guess I will not need that vote. ;-) -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Wed, 7 Aug 2002, Bruce Momjian wrote: > Tom Lane wrote: > > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > > OK, here is the request for vote. Do we want: > > > > > 1) the old secondary passwords re-added > > > 2) the new prefixing of the database name to the username when enabled > > > 3) do nothing > > > > I vote for 2b), username@database ... > > Yes, the format was going to be my second vote, dbname.username or > username@dbname. Guess I will not need that vote. ;-) Actually, I kinda like dbname.username myself ... it means that wne you do a SELECT of the pg_shadow file, it can be sorted in a useful manner (ie. grouped by database)
On Thu, 2002-08-08 at 03:27, Marc G. Fournier wrote:
> On Wed, 7 Aug 2002, Bruce Momjian wrote:
>
> > Tom Lane wrote:
> > > Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > > > OK, here is the request for vote. Do we want:
> > >
> > > > 1) the old secondary passwords re-added
> > > > 2) the new prefixing of the database name to the username when enabled
> > > > 3) do nothing
> > >
> > > I vote for 2b), username@database ...
> >
> > Yes, the format was going to be my second vote, dbname.username or
> > username@dbname. Guess I will not need that vote. ;-)
>
> Actually, I kinda like dbname.username myself ... it means that wne you do
> a SELECT of the pg_shadow file, it can be sorted in a useful manner (ie.
> grouped by database)
use a view :
create view pg_shadow_with_domain as select usename as fullname, case when (strpos(usename,'@') > 0)
then substr(usename,1,strpos(usename,'@')-1) else usename end as usename, case when
(strpos(usename,'@')> 0) then substr(usename,strpos(usename,'@')+1) else '' end as
usedomain, usesysid, usecreatedb, usetrace, usesuper, usecatupd, passwd,
valuntil from pg_shadow;
and sort as you wish ;)
For example, to get all bruces in all domains starting with an 'acc'
just do
select * from pg_shadow_with_domain where usename = 'bruce' and domain like 'acc%' ;
------------------
Hannu
> Some may say Marc has fair warning now -- but does anyone know > for sure that > NO ONE ELSE in the whole world isn't using this feature? Marc is > more in the > know than most, granted -- but if he found this use for the > feature others > may have as well that we don't even know about. > > But if the feature is not going to remain it needs to be prominently > documented as being removed in the release notes. And just remember all those reasons why people find MySQL easier to use than Postgres - the upgrade process... Chris
Hannu Krosing <hannu@tm.ee> writes:
> On Thu, 2002-08-08 at 03:27, Marc G. Fournier wrote:
>> Actually, I kinda like dbname.username myself ... it means that wne you do
>> a SELECT of the pg_shadow file, it can be sorted in a useful manner (ie.
>> grouped by database)
Hmm, Marc's got a point there...
> use a view :
Yeah, but it's painful to do that.
regards, tom lane
Ssshhhh....don't tell Curt that! ;) Greg On Wed, 2002-08-07 at 21:31, Tom Lane wrote: > Hannu Krosing <hannu@tm.ee> writes: > > On Thu, 2002-08-08 at 03:27, Marc G. Fournier wrote: > >> Actually, I kinda like dbname.username myself ... it means that wne you do > >> a SELECT of the pg_shadow file, it can be sorted in a useful manner (ie. > >> grouped by database) > > Hmm, Marc's got a point there... > > > use a view : > > Yeah, but it's painful to do that. > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster
On Thu, 2002-08-08 at 07:31, Tom Lane wrote: > Hannu Krosing <hannu@tm.ee> writes: > > On Thu, 2002-08-08 at 03:27, Marc G. Fournier wrote: > >> Actually, I kinda like dbname.username myself ... it means that wne you do > >> a SELECT of the pg_shadow file, it can be sorted in a useful manner (ie. > >> grouped by database) > > Hmm, Marc's got a point there... > > > use a view : > > Yeah, but it's painful to do that. Not if the view is installed with the system. So the plan could be: 1 .give the new functionality in a "light" version - ie just checking at connect time, full name must be used when creating user. 2. modify pg_user to show it usename usedomain as two separate fields for eas of use (join pg_user and pg_shadow on usesysid if you need to see passwords) 3. in version 7.4 modify CREATE USER and ALTER USER to save the domain info in pg_shadow.usedomain. ----------------- Hannu
Hannu Krosing <hannu@tm.ee> writes:
> 2. modify pg_user to show it usename usedomain as two separate fields
> for eas of use (join pg_user and pg_shadow on usesysid if you need to
> see passwords)
This is already more mechanism than I wanted to buy into, and less
forethought than I think we need. For example, is it a good idea if
pg_user shows usernames that cannot be identified with those shown by
ACL lists? If not, how will you modify ACL I/O formats? What about
the has_table_privilege functions?
What I'm envisioning is an extremely limited facility that just maps
connection parameters into an internal username that is of the form
username@dbname or dbname.username. Trying to hide that internal
username for inside-the-database activities does not strike me as a
good plan.
This may prove to be just a stopgap measure that we'll replace down the
road (as indeed the secondary-passwords thing was just a stopgap, IMO).
Let's not add features that will create extra compatibility problems
if we abandon the whole approach later.
regards, tom lane
I would like to address this email.
Lamar is mentioning that it is unfair to remove a feature without
warning.
Let me give a little history. The secondary password file was created
at a time when we didn't encrypt with random salt over the wire, and we
had people who wanted to share their /etc/passwd file with PostgreSQL.
Later, people wanted to use the secondary password file for just
usernames, so you could list usernames in the file and limit db access
by user. This is the current usage for 99% of secondary password users.
This capability is better served in 7.3 with the new USER column in
pg_shadow and the ability to specify filenames or groups in that file.
Keeping the secondary password file to specify a user list while a new
USER column exists in 7.3 is just confusing to administrators. Our
pg_hba.conf system is pretty complex, so anything we can do to simplify
helps.
Now, on to Marc's case, where he does use the file for usernames _and_
passwords. However, he is using it only so he can have more than one
person with the same username and restrict access based on the password
in the secondary password file. While this does work, my submitted
patch makes this much easier and cleaner.
Marc had mentioned that this should be an initdb flag. However, our
standard procedure is to put stuff in initdb only when it can't be
changed after initdb. While strange, this feature can be
enabled-disabled after initdb. A quick update of pg_shadow can change
usernames and you can go in and out of this mode.
Someone talked about pushing this capability into a separate pg_shadow
column, and making CREATE/ALTER user and createuser aware of this.
While this can be done, and it sort of becomes user schemas, there isn't
enough people wanting this to add complexity to those commands. A GUC
flag will meet most peoples needs at this point.
Some mentioned using user@dbname, though the idea of sorting made
several recant their votes.
So, based on the voting, I think dbname.username is an agreed-upon
feature addition for 7.3. I will work on a final patch with
documentation and post it to the patches list for more comment.
---------------------------------------------------------------------------
Lamar Owen wrote:
> On Tuesday 06 August 2002 09:24 pm, Marc G. Fournier wrote:
> > On Tue, 6 Aug 2002, Bruce Momjian wrote:
> > > It had such limited usefulness ('password' only, only crypted-hashed
> > > passwords in the file) that it doesn't make much sense to resurect it.
>
> > It had limited usefulness to you ... but how many sites out there are
> > going to break when they try to upgraded without it there? I do agree
> > that it needs to improved / replaced, but without a suitable replacement
> > in place, the old should be resurrected until such a suitable one is in
> > place ...
>
> While it appears I'll be outvoted on this issue, and even though I agree that
> the existing functionality is broken, and even though I am not using the
> functionality, I am reminded of the overall policy that we have historically
> had about removing even broken features. Fair Warning must be given. If that
> policy is going to be changed, then it needs to be applied with equal vigor
> to all affected cases.
>
> Even if Marc is the only one using this feature, we should follow established
> policy -- that is, after all, what policy is for. To me it seems it is being
> yanked gratuitously without fair warning. If every question is answered on a
> case-by-case basis like this, we will descend to anarchy, I'm afraid. And,
> Bruce, I even agree with your reasons -- I just disagree with the method.
>
> Is it going to cause a major problem for it to remain one release cycle while
> someone works on a suitable replacement, with the warning in the release
> notes that while this feature is there for backwards compatibility that it
> will be yanked at the next release? And I'm not talking about a minor
> problem like 'more people will start using it' -- I'm talking 'if it stays we
> will be in danger of massive data corruption or exposure' -- of course,
> documenting that there is a degree of exposure of data if not set up in an
> exacting method, as Marc seems to have done.
>
> Some may say Marc has fair warning now -- but does anyone know for sure that
> NO ONE ELSE in the whole world isn't using this feature? Marc is more in the
> know than most, granted -- but if he found this use for the feature others
> may have as well that we don't even know about.
>
> But if the feature is not going to remain it needs to be prominently
> documented as being removed in the release notes.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073
On Tue, Jul 30, 2002 at 11:50:38PM -0400, Bruce Momjian wrote: > ecpg and bison issues - solved? Not solved yet. And it's just a matter of time until we run into it with the main parser grammar file as well. Bison upstream is working on removing all those short ints, but I have yet to receive a version that compiles ecpg grammar correctly. No idea, if this will be fixed in the next month. Michael -- Michael Meskes Michael@Fam-Meskes.De Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
Michael Meskes <meskes@postgresql.org> writes: > On Tue, Jul 30, 2002 at 11:50:38PM -0400, Bruce Momjian wrote: >> ecpg and bison issues - solved? > Not solved yet. And it's just a matter of time until we run into it with > the main parser grammar file as well. Yeah, I've been worrying about that too. Any idea how close we are to trouble in the main grammar? > Bison upstream is working on > removing all those short ints, but I have yet to receive a version that > compiles ecpg grammar correctly. If no solution is forthcoming, we might have to adopt plan B: find another parser-generator tool. Whilst googling for bison info I came across "Why Bison is Becoming Extinct"http://www.acm.org/crossroads/xrds7-5/bison.html which is a tad amusing at least. Now, it's anyone's guess whether any of the tools he suggests are actually ready for prime time; they might have practical limits much worse than bison's. But I got awfully frustrated yesterday trying (once again) to get bison to allow a schema-qualified type name in the syntax <typename> <literal string>. I'm just about ready to consider alternatives. Plan C would be to devote some work to minimizing the number of states in the main grammar (I assume it's number of states that's the problem). I doubt anyone's ever tried, so there might be enough low-hanging fruit to get ecpg off the hook for awhile. regards, tom lane
On Saturday 10 August 2002 10:41 pm, Bruce Momjian wrote: > Let me give a little history. The secondary password file was created > at a time when we didn't encrypt with random salt over the wire, and we > had people who wanted to share their /etc/passwd file with PostgreSQL. [snip] > So, based on the voting, I think dbname.username is an agreed-upon > feature addition for 7.3. I will work on a final patch with > documentation and post it to the patches list for more comment. I can live with this, if the documentation is prominently referred to in the changelog. As to the feature itself, I believe Bruce's proposed solution is the best, and believed that from the beginning -- I just wanted to deal with the 'fair warning' issue alone. As to fair warning: watch for the next RPM release. Fair Warning is being given that upgrades within the RPM context will not be supported in any form for the final release of PostgreSQL 7.3. I had a 'd'oh' moment (and I don't watch the Simpsons....) when I realized that I could quite easily prevent anyone from even attempting an RPM upgrade, unless that take matters into their own grubby little hands with special switches to the rpm command line. It will not be yanked this next set, but the following set will be unupgradable. Sorry, but the packaged kludge isn't reliable enough for the state of PostgreSQL reliability, and I don't want the RPMset's shortcomings (due to the whole RPM mechanism forcing the issue) causing bad blood towards PostgreSQL in general. The Debian packages don't have much of the limitations and restrictions I have to deal with, and until a good upgrade utility is available I'm just going to have to do this. I have been so swamped with Fortran work for work that I've not even looked at the python code Hannu so kindly sent me, nor have I played any more with pg_fsck. Groundwave propagation modeling in Fortran has been more important... Likewise, my focus as RPM maintainer is changing with this next release. Since the distributions, such as Red Hat, are doing a great job keeping up to date, I'm going to not bother much with building RPMs that are, frankly, redundant at this point. Three years ago it wasn't this nice. Trond has done a good job on the Red Hat bleeding edge front, Reinhard Max has done similarly for SuSE. There are PLD, Connectiva, TurboLinux, Caldera, and Mandrake maintainers as well -- and they seem to be doing fine. I'm going to now go to the lagging plane -- building newer PostgreSQL for older Red Hat (and maybe others, if I can get enough hard drives available). The source RPM will still be useful to the newer distribution's maintainers -- but the requests I see more of on the lists is newer PostgreSQL on older linux. So I'm going to try to rise to that occassion, and take this opportunity to apologize for not seeing it sooner. I welcome comments on this change of focus. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
On Mon, 2002-08-12 at 21:28, Lamar Owen wrote: > I'm going to now go to the lagging plane -- building newer PostgreSQL for > older Red Hat (and maybe others, if I can get enough hard drives available). > The source RPM will still be useful to the newer distribution's maintainers > -- but the requests I see more of on the lists is newer PostgreSQL on older > linux. So I'm going to try to rise to that occassion, and take this > opportunity to apologize for not seeing it sooner. > > I welcome comments on this change of focus. Even though we run redhat on our systems, as close to stock as we can, I have found that your RPMs build more reliably than Trond's. My bad for being unable to diagnose the build problems with the RedHat SRPM, my double-bad for letting that failure prevent my reporting the issu to him. But I for one will miss your lead on the bleeding edge of RPM development. -- Karl DeBisschop
On Monday 12 August 2002 09:51 pm, Karl DeBisschop wrote: > On Mon, 2002-08-12 at 21:28, Lamar Owen wrote: > > I'm going to now go to the lagging plane -- building newer PostgreSQL for > > older Red Hat (and maybe others, if I can get enough hard drives > > available). The source RPM will still be useful to the newer > > distribution's maintainers -- but the requests I see more of on the lists > > is newer PostgreSQL on older linux. So I'm going to try to rise to that > > occassion, and take this opportunity to apologize for not seeing it > > sooner. > But I for one will miss your lead on the bleeding edge of RPM > development. Oh, I've misstated, apparently. I'll continue on the 'bleeding edge' as far as versions of PostgreSQL are concerned -- I'm just shifting focus to providing prebuilt binaries on older dists. As I do some other bleeding edge work, I typically will make sure my source RPM's build on the latest and greatest -- they just won't be optimized for it. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
> Some mentioned using user@dbname, though the idea of sorting made > several recant their votes. > > So, based on the voting, I think dbname.username is an agreed-upon > feature addition for 7.3. I will work on a final patch with > documentation and post it to the patches list for more comment. The nice thing about using an @ sign, amongst being more consistent with kerberos and email, is that it doesn't preclude the use of .'s in a database name. For simplicity's sake, I'd really like to be able to continue issuing database names that are identical to the domain that they serve and worry that relying on a "." will either make the use of a dot in the username or database impossible. An @ sign, on the other hand, is the ubiquitously agreed upon username/host separator and makes it all that much more consistent for users and administrators. Username: john.doe Database: foo.com possible pg_shadow entry #1: john.doe.foo.com possible pg_shadow entry #2: john.doe@foo.com If people are worried about the sorting, ORDER BY domain, username. My $0.02. -sc -- Sean Chittenden
Sean Chittenden wrote: > > Some mentioned using user@dbname, though the idea of sorting made > > several recant their votes. > > > > So, based on the voting, I think dbname.username is an agreed-upon > > feature addition for 7.3. I will work on a final patch with > > documentation and post it to the patches list for more comment. > > The nice thing about using an @ sign, amongst being more consistent > with kerberos and email, is that it doesn't preclude the use of .'s in > a database name. For simplicity's sake, I'd really like to be able to > continue issuing database names that are identical to the domain that > they serve and worry that relying on a "." will either make the use of > a dot in the username or database impossible. An @ sign, on the other > hand, is the ubiquitously agreed upon username/host separator and > makes it all that much more consistent for users and administrators. > > Username: john.doe > Database: foo.com > possible pg_shadow entry #1: john.doe.foo.com > possible pg_shadow entry #2: john.doe@foo.com > > If people are worried about the sorting, ORDER BY domain, username. > My $0.02. -sc Well, they aren't separate fields so you can't ORDER BY domain. The dot was used so it looks like a schema based on dbname. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
> > > Some mentioned using user@dbname, though the idea of sorting made > > > several recant their votes. > > > > > > So, based on the voting, I think dbname.username is an agreed-upon > > > feature addition for 7.3. I will work on a final patch with > > > documentation and post it to the patches list for more comment. > > > > The nice thing about using an @ sign, amongst being more consistent > > with kerberos and email, is that it doesn't preclude the use of .'s in > > a database name. For simplicity's sake, I'd really like to be able to > > continue issuing database names that are identical to the domain that > > they serve and worry that relying on a "." will either make the use of > > a dot in the username or database impossible. An @ sign, on the other > > hand, is the ubiquitously agreed upon username/host separator and > > makes it all that much more consistent for users and administrators. > > > > Username: john.doe > > Database: foo.com > > possible pg_shadow entry #1: john.doe.foo.com > > possible pg_shadow entry #2: john.doe@foo.com > > > > If people are worried about the sorting, ORDER BY domain, username. > > My $0.02. -sc > > Well, they aren't separate fields so you can't ORDER BY domain. The dot > was used so it looks like a schema based on dbname. Sorry, I know it's a single field and that there is no split() function (that I'm aware of), but that seems like such a small and easy to fix problem that I personally place a higher value on the more standard nomeclature and use of an @ sign. I understand the value of . for schemas and whatnot, but isn't a user going to be in their own schema to begin with? As for the order by, I've got a list of users per "account" (sales account), so doing the order by is on two columns and the pg_shadow table is generated periodically from our inhouse tables. -sc -- Sean Chittenden
Sean Chittenden wrote: > > Well, they aren't separate fields so you can't ORDER BY domain. The dot > > was used so it looks like a schema based on dbname. > > Sorry, I know it's a single field and that there is no split() > function (that I'm aware of), but that seems like such a small and > easy to fix problem that I personally place a higher value on the more > standard nomeclature and use of an @ sign. I understand the value of > . for schemas and whatnot, but isn't a user going to be in their own > schema to begin with? As for the order by, I've got a list of users > per "account" (sales account), so doing the order by is on two columns > and the pg_shadow table is generated periodically from our inhouse > tables. -sc I have no personal preference between period and @ or whatever. See if you can get some other votes for @ because most left @ when the ORDER BY idea came up from Marc. As for it being a special character, it really isn't because the code prepends the database name and a period. It doesn't look to see if there is a period in the already or anything. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
OK, here is the patch to implement db_user_namespace. It includes documentation. I had to add to initdb to create a file /data/PG_INSTALLER and have the postmaster read that on startup to determine the installing user. --------------------------------------------------------------------------- Bruce Momjian wrote: > > I would like to address this email. > > Lamar is mentioning that it is unfair to remove a feature without > warning. > > Let me give a little history. The secondary password file was created > at a time when we didn't encrypt with random salt over the wire, and we > had people who wanted to share their /etc/passwd file with PostgreSQL. > > Later, people wanted to use the secondary password file for just > usernames, so you could list usernames in the file and limit db access > by user. This is the current usage for 99% of secondary password users. > This capability is better served in 7.3 with the new USER column in > pg_shadow and the ability to specify filenames or groups in that file. > Keeping the secondary password file to specify a user list while a new > USER column exists in 7.3 is just confusing to administrators. Our > pg_hba.conf system is pretty complex, so anything we can do to simplify > helps. > > Now, on to Marc's case, where he does use the file for usernames _and_ > passwords. However, he is using it only so he can have more than one > person with the same username and restrict access based on the password > in the secondary password file. While this does work, my submitted > patch makes this much easier and cleaner. > > Marc had mentioned that this should be an initdb flag. However, our > standard procedure is to put stuff in initdb only when it can't be > changed after initdb. While strange, this feature can be > enabled-disabled after initdb. A quick update of pg_shadow can change > usernames and you can go in and out of this mode. > > Someone talked about pushing this capability into a separate pg_shadow > column, and making CREATE/ALTER user and createuser aware of this. > While this can be done, and it sort of becomes user schemas, there isn't > enough people wanting this to add complexity to those commands. A GUC > flag will meet most peoples needs at this point. > > Some mentioned using user@dbname, though the idea of sorting made > several recant their votes. > > So, based on the voting, I think dbname.username is an agreed-upon > feature addition for 7.3. I will work on a final patch with > documentation and post it to the patches list for more comment. > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 Index: doc/src/sgml/runtime.sgml =================================================================== RCS file: /cvsroot/pgsql-server/doc/src/sgml/runtime.sgml,v retrieving revision 1.124 diff -c -r1.124 runtime.sgml *** doc/src/sgml/runtime.sgml 12 Aug 2002 00:36:11 -0000 1.124 --- doc/src/sgml/runtime.sgml 14 Aug 2002 01:30:15 -0000 *************** *** 1191,1196 **** --- 1191,1208 ---- </varlistentry> <varlistentry> + <term><varname>DB_USER_NAMESPACE</varname> (<type>boolean</type>)</term> + <listitem> + <para> + Prepends the database name and a period to the username when + connecting to the database. This allows per-database users. + The user who ran <command>initdb</> is excluded from this + handling. + </para> + </listitem> + </varlistentry> + + <varlistentry> <indexterm> <primary>deadlock</primary> <secondary>timeout</secondary> Index: src/backend/libpq/auth.c =================================================================== RCS file: /cvsroot/pgsql-server/src/backend/libpq/auth.c,v retrieving revision 1.82 diff -c -r1.82 auth.c *** src/backend/libpq/auth.c 20 Jun 2002 20:29:28 -0000 1.82 --- src/backend/libpq/auth.c 14 Aug 2002 01:30:15 -0000 *************** *** 117,123 **** version, PG_KRB4_VERSION); return STATUS_ERROR; } ! if (strncmp(port->user, auth_data.pname, SM_USER) != 0) { elog(LOG, "pg_krb4_recvauth: name \"%s\" != \"%s\"", port->user, auth_data.pname); --- 117,123 ---- version, PG_KRB4_VERSION); return STATUS_ERROR; } ! if (strncmp(port->user, auth_data.pname, SM_DATABASE_USER) != 0) { elog(LOG, "pg_krb4_recvauth: name \"%s\" != \"%s\"", port->user, auth_data.pname); *************** *** 290,296 **** } kusername = pg_an_to_ln(kusername); ! if (strncmp(port->user, kusername, SM_USER)) { elog(LOG, "pg_krb5_recvauth: user name \"%s\" != krb5 name \"%s\"", port->user, kusername); --- 290,296 ---- } kusername = pg_an_to_ln(kusername); ! if (strncmp(port->user, kusername, SM_DATABASE_USER)) { elog(LOG, "pg_krb5_recvauth: user name \"%s\" != krb5 name \"%s\"", port->user, kusername); Index: src/backend/postmaster/postmaster.c =================================================================== RCS file: /cvsroot/pgsql-server/src/backend/postmaster/postmaster.c,v retrieving revision 1.283 diff -c -r1.283 postmaster.c *** src/backend/postmaster/postmaster.c 10 Aug 2002 20:29:18 -0000 1.283 --- src/backend/postmaster/postmaster.c 14 Aug 2002 01:30:17 -0000 *************** *** 116,122 **** sigset_t UnBlockSig, BlockSig, AuthBlockSig; - #else int UnBlockSig, BlockSig, --- 116,121 ---- *************** *** 191,196 **** --- 190,197 ---- bool HostnameLookup; /* for ps display */ bool ShowPortNumber; bool Log_connections = false; + bool Db_user_namespace = false; + /* Startup/shutdown state */ static pid_t StartupPID = 0, *************** *** 208,213 **** --- 209,216 ---- bool ClientAuthInProgress = false; /* T during new-client authentication */ + static char InstallUser[SM_USER+1]; + /* * State for assigning random salts and cancel keys. * Also, the global MyCancelKey passes the cancel key assigned to a given *************** *** 258,263 **** --- 261,267 ---- static void SignalChildren(int signal); static int CountChildren(void); static bool CreateOptsFile(int argc, char *argv[]); + static bool GetInstallUser(void); static pid_t SSDataBase(int xlop); void postmaster_error(const char *fmt,...) *************** *** 690,695 **** --- 694,702 ---- if (!CreateOptsFile(argc, argv)) ExitPostmaster(1); + if (!GetInstallUser()) + ExitPostmaster(1); + /* * Set up signal handlers for the postmaster process. * *************** *** 1161,1166 **** --- 1168,1182 ---- if (port->user[0] == '\0') elog(FATAL, "no PostgreSQL user name specified in startup packet"); + /* Prefix database name for per-db user namespace */ + if (Db_user_namespace && strcmp(port->user, InstallUser)) + { + char hold_user[SM_DATABASE_USER]; + snprintf(hold_user, SM_DATABASE_USER, "%s.%s", port->database, + port->user); + strcpy(port->user, hold_user); + } + /* * If we're going to reject the connection due to database state, say * so now instead of wasting cycles on an authentication exchange. *************** *** 2587,2597 **** if (FindExec(fullprogname, argv[0], "postmaster") < 0) return false; ! filename = palloc(strlen(DataDir) + 20); sprintf(filename, "%s/postmaster.opts", DataDir); ! fp = fopen(filename, "w"); ! if (fp == NULL) { postmaster_error("cannot create file %s: %s", filename, strerror(errno)); --- 2603,2612 ---- if (FindExec(fullprogname, argv[0], "postmaster") < 0) return false; ! filename = palloc(strlen(DataDir) + 17); sprintf(filename, "%s/postmaster.opts", DataDir); ! if ((fp = fopen(filename, "w")) == NULL) { postmaster_error("cannot create file %s: %s", filename, strerror(errno)); *************** *** 2614,2619 **** --- 2629,2669 ---- return true; } + /* + * Load install user so db_user_namespace can skip it. + */ + static bool + GetInstallUser(void) + { + char *filename; + FILE *fp; + + filename = palloc(strlen(DataDir) + 14); + sprintf(filename, "%s/PG_INSTALLER", DataDir); + + if ((fp = fopen(filename, "r")) == NULL) + { + postmaster_error("cannot open file %s: %s", + filename, strerror(errno)); + return false; + } + + if (fgets(InstallUser, SM_USER+1, fp) == NULL) + { + postmaster_error("cannot read file %s: %s", + filename, strerror(errno)); + return false; + } + + /* Trim off trailing newline */ + if (strchr(InstallUser, '\n') != NULL) + *strchr(InstallUser, '\n') = '\0'; + + fclose(fp); + return true; + } + + /* * This should be used only for reporting "interactive" errors (ie, errors * during startup. Once the postmaster is launched, use elog. Index: src/backend/utils/misc/guc.c =================================================================== RCS file: /cvsroot/pgsql-server/src/backend/utils/misc/guc.c,v retrieving revision 1.79 diff -c -r1.79 guc.c *** src/backend/utils/misc/guc.c 12 Aug 2002 00:36:11 -0000 1.79 --- src/backend/utils/misc/guc.c 14 Aug 2002 01:30:20 -0000 *************** *** 482,487 **** --- 482,491 ---- { "transform_null_equals", PGC_USERSET }, &Transform_null_equals, false, NULL, NULL }, + { + { "db_user_namespace", PGC_SIGHUP }, &Db_user_namespace, + false, NULL, NULL + }, { { NULL, 0 }, NULL, false, NULL, NULL Index: src/backend/utils/misc/postgresql.conf.sample =================================================================== RCS file: /cvsroot/pgsql-server/src/backend/utils/misc/postgresql.conf.sample,v retrieving revision 1.44 diff -c -r1.44 postgresql.conf.sample *** src/backend/utils/misc/postgresql.conf.sample 12 Aug 2002 00:36:12 -0000 1.44 --- src/backend/utils/misc/postgresql.conf.sample 14 Aug 2002 01:30:20 -0000 *************** *** 113,119 **** # # Message display # - #server_min_messages = notice # Values, in order of decreasing detail: # debug5, debug4, debug3, debug2, debug1, # info, notice, warning, error, log, fatal, --- 113,118 ---- *************** *** 201,203 **** --- 200,203 ---- #sql_inheritance = true #transform_null_equals = false #statement_timeout = 0 # 0 is disabled + #db_user_namespace = false Index: src/bin/initdb/initdb.sh =================================================================== RCS file: /cvsroot/pgsql-server/src/bin/initdb/initdb.sh,v retrieving revision 1.165 diff -c -r1.165 initdb.sh *** src/bin/initdb/initdb.sh 8 Aug 2002 19:39:05 -0000 1.165 --- src/bin/initdb/initdb.sh 14 Aug 2002 01:30:20 -0000 *************** *** 603,608 **** --- 603,613 ---- # Top level PG_VERSION is checked by bootstrapper, so make it first echo "$short_version" > "$PGDATA/PG_VERSION" || exit_nicely + # Top level PG_INSTALLER is used by db_user_namespace to prevent username + # mapping just for the install user. + echo "$POSTGRES_SUPERUSERNAME" > "$PGDATA/PG_INSTALLER" || exit_nicely + + cat "$POSTGRES_BKI" \ | sed -e "s/POSTGRES/$POSTGRES_SUPERUSERNAME/g" \ -e "s/ENCODING/$MULTIBYTEID/g" \ Index: src/include/libpq/libpq-be.h =================================================================== RCS file: /cvsroot/pgsql-server/src/include/libpq/libpq-be.h,v retrieving revision 1.32 diff -c -r1.32 libpq-be.h *** src/include/libpq/libpq-be.h 20 Jun 2002 20:29:49 -0000 1.32 --- src/include/libpq/libpq-be.h 14 Aug 2002 01:30:20 -0000 *************** *** 59,65 **** ProtocolVersion proto; char database[SM_DATABASE + 1]; ! char user[SM_USER + 1]; char options[SM_OPTIONS + 1]; char tty[SM_TTY + 1]; char auth_arg[MAX_AUTH_ARG]; --- 59,65 ---- ProtocolVersion proto; char database[SM_DATABASE + 1]; ! char user[SM_DATABASE_USER + 1]; char options[SM_OPTIONS + 1]; char tty[SM_TTY + 1]; char auth_arg[MAX_AUTH_ARG]; *************** *** 72,78 **** SSL *ssl; X509 *peer; char peer_dn[128 + 1]; ! char peer_cn[SM_USER + 1]; unsigned long count; #endif } Port; --- 72,78 ---- SSL *ssl; X509 *peer; char peer_dn[128 + 1]; ! char peer_cn[SM_DATABASE_USER + 1]; unsigned long count; #endif } Port; Index: src/include/libpq/pqcomm.h =================================================================== RCS file: /cvsroot/pgsql-server/src/include/libpq/pqcomm.h,v retrieving revision 1.65 diff -c -r1.65 pqcomm.h *** src/include/libpq/pqcomm.h 12 Aug 2002 14:35:26 -0000 1.65 --- src/include/libpq/pqcomm.h 14 Aug 2002 01:30:20 -0000 *************** *** 114,119 **** --- 114,121 ---- #define SM_DATABASE 64 /* SM_USER should be the same size as the others. bjm 2002-06-02 */ #define SM_USER 32 + /* We prepend database name if db_user_namespace true. */ + #define SM_DATABASE_USER (SM_DATABASE+SM_USER) #define SM_OPTIONS 64 #define SM_UNUSED 64 #define SM_TTY 64 *************** *** 124,135 **** --- 126,139 ---- { ProtocolVersion protoVersion; /* Protocol version */ char database[SM_DATABASE]; /* Database name */ + /* Db_user_namespace prepends dbname */ char user[SM_USER]; /* User name */ char options[SM_OPTIONS]; /* Optional additional args */ char unused[SM_UNUSED]; /* Unused */ char tty[SM_TTY]; /* Tty for debug output */ } StartupPacket; + extern bool Db_user_namespace; /* These are the authentication requests sent by the backend. */
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I have no personal preference between period and @ or whatever. See if
> you can get some other votes for @ because most left @ when the ORDER BY
> idea came up from Marc.
FWIW, I still lean to username@database, so I think we're roughly at a
tie. It would be good to get more votes ...
regards, tom lane
> Bruce Momjian <pgman@candle.pha.pa.us> writes: > > I have no personal preference between period and @ or whatever. See if > > you can get some other votes for @ because most left @ when the ORDER BY > > idea came up from Marc. > > FWIW, I still lean to username@database, so I think we're roughly at a > tie. It would be good to get more votes ... Sorry guys, I'm staying out of this one as my vote would be entirely arbitrary... Chris
On Wed, 2002-08-14 at 06:00, Bruce Momjian wrote: > Sean Chittenden wrote: > > > Well, they aren't separate fields so you can't ORDER BY domain. The dot > > > was used so it looks like a schema based on dbname. IMHO it should look like an user in domain ;) > > Sorry, I know it's a single field and that there is no split() > > function (that I'm aware of), but that seems like such a small and > > easy to fix problem that I personally place a higher value on the more > > standard nomeclature and use of an @ sign. I understand the value of > > . for schemas and whatnot, but isn't a user going to be in their own > > schema to begin with? As for the order by, I've got a list of users > > per "account" (sales account), so doing the order by is on two columns > > and the pg_shadow table is generated periodically from our inhouse > > tables. -sc > > I have no personal preference between period and @ or whatever. See if > you can get some other votes for @ because most left @ when the ORDER BY > idea came up from Marc. I still like @ . And I posted code that could be put in the pg_user view to split out domain you could ORDER BY. > As for it being a special character, it really isn't because the code > prepends the database name and a period. It doesn't look to see if > there is a period in the already or anything. ----------- Hannu
OK, the vote is not shifting from '.' to '@'. Is that how we want to go? I like the pg_user enhancement. Marc, comments? This was your baby. --------------------------------------------------------------------------- Hannu Krosing wrote: > On Wed, 2002-08-14 at 06:00, Bruce Momjian wrote: > > Sean Chittenden wrote: > > > > Well, they aren't separate fields so you can't ORDER BY domain. The dot > > > > was used so it looks like a schema based on dbname. > > IMHO it should look like an user in domain ;) > > > > Sorry, I know it's a single field and that there is no split() > > > function (that I'm aware of), but that seems like such a small and > > > easy to fix problem that I personally place a higher value on the more > > > standard nomeclature and use of an @ sign. I understand the value of > > > . for schemas and whatnot, but isn't a user going to be in their own > > > schema to begin with? As for the order by, I've got a list of users > > > per "account" (sales account), so doing the order by is on two columns > > > and the pg_shadow table is generated periodically from our inhouse > > > tables. -sc > > > > I have no personal preference between period and @ or whatever. See if > > you can get some other votes for @ because most left @ when the ORDER BY > > idea came up from Marc. > > I still like @ . And I posted code that could be put in the pg_user view > to split out domain you could ORDER BY. > > > As for it being a special character, it really isn't because the code > > prepends the database name and a period. It doesn't look to see if > > there is a period in the already or anything. > ----------- > Hannu > > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > >>I have no personal preference between period and @ or whatever. See if >>you can get some other votes for @ because most left @ when the ORDER BY >>idea came up from Marc. > > > FWIW, I still lean to username@database, so I think we're roughly at a > tie. It would be good to get more votes ... > I'm in favor of username@database too. Joe
> > > > Well, they aren't separate fields so you can't ORDER BY domain. The dot
> > > > was used so it looks like a schema based on dbname.
>
> IMHO it should look like an user in domain ;)
Agreed, but there is something to be said for doing a sort of users
per domain. This wouldn't be an issue, I don't think, if there was a
split_before() and split_after() like functions.
# SELECT split_before('user@domain.com','@'), split_after('user@domain.com', '@');?column? | ?column?
----------+------------user | domain.com
What would you guys say to submissions for a patch that would add the
function listed above? Maybe just a function called get_user(text)
and get_domain(text)? ::shrug:: Just some thoughts since there is
validity to being able to parse/operate on this data efficiently. If
those functions existed, then I think everyone would be able to have
their pie as they want it. -sc
--
Sean Chittenden
On Wed, 2002-08-14 at 12:45, Sean Chittenden wrote:
> > > > > Well, they aren't separate fields so you can't ORDER BY domain. The dot
> > > > > was used so it looks like a schema based on dbname.
> >
> > IMHO it should look like an user in domain ;)
>
> Agreed, but there is something to be said for doing a sort of users
> per domain. This wouldn't be an issue, I don't think, if there was a
> split_before() and split_after() like functions.
>
> # SELECT split_before('user@domain.com','@'), split_after('user@domain.com', '@');
> ?column? | ?column?
> ----------+------------
> user | domain.com
>
> What would you guys say to submissions for a patch that would add the
> function listed above?
create function split_before(text,text) returns text as 'select case when (strpos($1,$2) > 0) then
substr($1,1,strpos($1,$2)-1) else $1 end as usename
' language 'SQL';
create function split_after(text,text) returns text as 'select case when (strpos($1,$2) > 0) then
substr($1,strpos($1,$2)+1) else '''' end as usedomain
' language 'SQL' ;
hannu=# select split_before('me@somewhere','@'),
split_after('me@somewhere','@');split_before | split_after
--------------+-------------me | somewhere
(1 row)
-------------
Hannu
> > > > > > Well, they aren't separate fields so you can't ORDER BY domain. The dot
> > > > > > was used so it looks like a schema based on dbname.
> > >
> > > IMHO it should look like an user in domain ;)
> >
> > Agreed, but there is something to be said for doing a sort of users
> > per domain. This wouldn't be an issue, I don't think, if there was a
> > split_before() and split_after() like functions.
> >
> > # SELECT split_before('user@domain.com','@'), split_after('user@domain.com', '@');
> > ?column? | ?column?
> > ----------+------------
> > user | domain.com
> >
> > What would you guys say to submissions for a patch that would add the
> > function listed above?
>
> create function split_before(text,text) returns text as '
> select case when (strpos($1,$2) > 0)
> then substr($1,1,strpos($1,$2)-1)
> else $1
> end as usename
> ' language 'SQL';
>
> create function split_after(text,text) returns text as '
> select case when (strpos($1,$2) > 0)
> then substr($1,strpos($1,$2)+1)
> else ''''
> end as usedomain
> ' language 'SQL' ;
>
> hannu=# select split_before('me@somewhere','@'),
> split_after('me@somewhere','@');
> split_before | split_after
> --------------+-------------
> me | somewhere
> (1 row)
Oh that was handy and fast! I didn't know of strpos(). Cool, who
says 'ya can't learn something every day? :~) Now with an alias or
subselect, it should be very easy to order users in a domain in any
way that SQL allows. :~) Thanks Hannu. -sc
--
Sean Chittenden
I'm going to vote for either @ or %. On Wed, 2002-08-14 at 00:11, Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > I have no personal preference between period and @ or whatever. See if > > you can get some other votes for @ because most left @ when the ORDER BY > > idea came up from Marc. > > FWIW, I still lean to username@database, so I think we're roughly at a > tie. It would be good to get more votes ...
> OK, the vote is not shifting from '.' to '@'. Is that how we want to > go? I like the pg_user enhancement. Marc, comments? This was your > baby. > Would it be hard to setup an internal PG variable for the actual character to be used?
Sean Chittenden wrote:
> Agreed, but there is something to be said for doing a sort of users
> per domain. This wouldn't be an issue, I don't think, if there was a
> split_before() and split_after() like functions.
>
> # SELECT split_before('user@domain.com','@'), split_after('user@domain.com', '@');
> ?column? | ?column?
> ----------+------------
> user | domain.com
>
> What would you guys say to submissions for a patch that would add the
> function listed above? Maybe just a function called get_user(text)
> and get_domain(text)? ::shrug:: Just some thoughts since there is
> validity to being able to parse/operate on this data efficiently. If
> those functions existed, then I think everyone would be able to have
> their pie as they want it. -sc
>
I already have a function in contrib/dblink, currently called
dblink_strtok(), which I was going to turn into a builtin function per
recent discussion (renamed of course). It would work for this but is
more general:
dblink_strtok(text inputstring, text delimiter, int posn) RETURNS text
Inputs inputstring any string you want to parse a token out of; e.g. 'f=1&g=3&h=4' delimiter a single
characterto use as the delimiter; e.g. '&' or '=' posn the position of the token of interest, 0 based; e.g.
1
Should it be called splitstr() (similar to substr())?
Joe
On Wed, Aug 14, 2002 at 12:11:10AM -0400, Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > I have no personal preference between period and @ or whatever. See if > > you can get some other votes for @ because most left @ when the ORDER BY > > idea came up from Marc. > > FWIW, I still lean to username@database, so I think we're roughly at a > tie. It would be good to get more votes ... My non-coding vote goes to user@database, too. A -- ---- Andrew Sullivan 87 Mowat Avenue Liberty RMS Toronto, Ontario Canada <andrew@libertyrms.info> M6K 3E3 +1 416 646 3304 x110
On Wed, 2002-08-14 at 16:08, Joe Conway wrote: > I already have a function in contrib/dblink, currently called > dblink_strtok(), which I was going to turn into a builtin function per > recent discussion (renamed of course). It would work for this but is > more general: > > dblink_strtok(text inputstring, text delimiter, int posn) RETURNS text > > Inputs > inputstring > any string you want to parse a token out of; > e.g. 'f=1&g=3&h=4' > delimiter > a single character to use as the delimiter; > e.g. '&' or '=' > posn > the position of the token of interest, 0 based; > e.g. 1 > > Should it be called splitstr() (similar to substr())? What about functions 1. split(text,text,int) returns text 2. split(text,text) returns text[] and why not 3. split(text,text,text) returns text which returns text from $1 delimited by $2 and $3 ------------- Hannu
On Tuesday 13 August 2002 07:21 pm, Sander Steffann wrote: > I think choosing . as the delimiter is a dangerous choice... People have > not expected it to be special until now, so maybe another character can be > chosen? I would suggest a colon if possible, so you would get dbname:user. > I don't expect that a lot of people use a colon as the dbname or username, > but I could be very wrong here. The choices have been enumerated as . and @. I personally vote for either: user@db OR db!user (sorry, having been a UUCP node admin shows at times...) To my eyes the bang notation is more of a 'divider' than the @. Unless there is some _really_ good reason to not use !, that is. :-) -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
ngpg@grymmjack.com dijo: > > OK, the vote is not shifting from '.' to '@'. Is that how we want to > > go? I like the pg_user enhancement. Marc, comments? This was your > > baby. > > Would it be hard to setup an internal PG variable for the actual character > to be used? That'd be good, because almost any character people wants to use as delimiter is actually valid in database and user names. So giving people a choice is a good thing. For example someone may want to use email address as usernames, and that messes up the splitting on @. -- Alvaro Herrera (<alvherre[a]atentus.com>) "Cuando miro a alguien, mas me atrae como cambia que quien es" (J. Binoche)
We are clearly going for user@db now. --------------------------------------------------------------------------- Lamar Owen wrote: > On Tuesday 13 August 2002 07:21 pm, Sander Steffann wrote: > > I think choosing . as the delimiter is a dangerous choice... People have > > not expected it to be special until now, so maybe another character can be > > chosen? I would suggest a colon if possible, so you would get dbname:user. > > I don't expect that a lot of people use a colon as the dbname or username, > > but I could be very wrong here. > > The choices have been enumerated as . and @. I personally vote for either: > user@db > OR > db!user > (sorry, having been a UUCP node admin shows at times...) To my eyes the bang > notation is more of a 'divider' than the @. Unless there is some _really_ > good reason to not use !, that is. :-) > -- > Lamar Owen > WGCR Internet Radio > 1 Peter 4:11 > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian writes: > I had to add to initdb to create a file /data/PG_INSTALLER and have the > postmaster read that on startup to determine the installing user. I object to treating one user specially. There should be a general mechanism, such as a separate column in pg_shadow. I also object to fixing the name during initdb. We just got rid of that requirement. If it mattered, I would also object to the choice of the file name. -- Peter Eisentraut peter_e@gmx.net
OK, what I didn't want to do we to over-complexify something that is for only a few users. In a way that user has to be special for this case because of the requirement that at least one person be able to connect when you flip that flag. Also, I don't want to add a column to pg_shadow. Seems like overkill. Please suggest another name for the file. Basically, I am not going to stop working on something when one person objects or this will never get done, and I think we have had enough feedback on this that people do want this done. --------------------------------------------------------------------------- Peter Eisentraut wrote: > Bruce Momjian writes: > > > I had to add to initdb to create a file /data/PG_INSTALLER and have the > > postmaster read that on startup to determine the installing user. > > I object to treating one user specially. There should be a general > mechanism, such as a separate column in pg_shadow. > > I also object to fixing the name during initdb. We just got rid of that > requirement. > > If it mattered, I would also object to the choice of the file name. > > -- > Peter Eisentraut peter_e@gmx.net > > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
This email brings up another issue I have seen recently. The use of the word "object", "strongly object", or "*object*" with stars is a very confrontational way to express things. It does not foster discussion; it really puts your heal in the ground and presents a very unswerving attitude when it really isn't necessary nor valuable. It is not just this email, but several people on this list who are doing that now, and it is making for more negative discussions. Thomas has mentioned it too. As I have said before, everyone gets one vote. It doesn't matter how hard to "object" to something. It is the force of your argument that affects the votes, not how strongly you express your dislike of something. One effect of this environment is that you end up coding to avoid "objections" rather than coding to meet users needs. Certainly the people who express objections are providing valuable feedback to help improve patches/features, but it should be done in a way that doesn't give the impression they are in a courtroom and when you post something incorrect, some lawyer is going to jump up and yell "object". --------------------------------------------------------------------------- Peter Eisentraut wrote: > Bruce Momjian writes: > > > I had to add to initdb to create a file /data/PG_INSTALLER and have the > > postmaster read that on startup to determine the installing user. > > I object to treating one user specially. There should be a general > mechanism, such as a separate column in pg_shadow. > > I also object to fixing the name during initdb. We just got rid of that > requirement. > > If it mattered, I would also object to the choice of the file name. > > -- > Peter Eisentraut peter_e@gmx.net > > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> In a way that user has to be special for this case
> because of the requirement that at least one person be able to connect
> when you flip that flag.
Why does anyone need to be special? The behavior should be to try the
given user name, and if that's not found then to try user@db. I see no
need to special-case any user.
> Basically, I am not going to stop working on something when one person
> objects or this will never get done,
He didn't say to stop working on it. He said to fix the misdesigned
parts. And I quite agree that those parts are misdesigned.
regards, tom lane
I believe the dictionary meaning of 'object' in this context would be 'a cause for concern or attention'. Each of Peters uses of the word is highly appropriate, as he was concerned and I'd agree with the sentiments that those concepts needed attention. Anyway, object with stars and strongly object are definitely leaning towards abuse of the word. On Wed, 2002-08-14 at 13:35, Bruce Momjian wrote: > > This email brings up another issue I have seen recently. The use of the > word "object", "strongly object", or "*object*" with stars is a very > > > I had to add to initdb to create a file /data/PG_INSTALLER and have the > > > postmaster read that on startup to determine the installing user. > > > > I object to treating one user specially. There should be a general > > mechanism, such as a separate column in pg_shadow. > > > > I also object to fixing the name during initdb. We just got rid of that > > requirement. > > > > If it mattered, I would also object to the choice of the file name.
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > In a way that user has to be special for this case > > because of the requirement that at least one person be able to connect > > when you flip that flag. > > Why does anyone need to be special? The behavior should be to try the > given user name, and if that's not found then to try user@db. I see no > need to special-case any user. Oh, so try it with and without. I can do that, but it seems more of a security problem where you were trying two names instead of one. Do people like that? It is easy to do, except for the fact we have to match pg_hba.conf with a username, though we could do the double-test there too, if that isn't too weird. > > Basically, I am not going to stop working on something when one person > > objects or this will never get done, > > He didn't say to stop working on it. He said to fix the misdesigned > parts. And I quite agree that those parts are misdesigned. I will fix them as long as the fixes don't generate new objections, like adding a new column to pg_shadow. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Oh, so try it with and without. I can do that, but it seems more of a
> security problem where you were trying two names instead of one. Do
> people like that?
The nice thing about it is you can have any combination of people with
installation-wide access (create them as joeblow) and people with
one-database access (create them as joeblow@joesdatabase). A special
case for only the postgres user is much less flexible.
> It is easy to do, except for the fact we have to
> match pg_hba.conf with a username, though we could do the double-test
> there too, if that isn't too weird.
It'd probably be better to first look at the flat-file copy of pg_shadow
to determine whether user or user@database is the form to use, and then
run through pg_hba.conf only once using the correct form. Otherwise
there are going to be all sorts of weird corner cases: user might match
a different pg_hba row than user@database does.
Also, if you do it this way then the substitution only has to be done in
one place: you can pass down the correct form to the backend, which'd
otherwise have to repeat the test to see which username is found.
regards, tom lane
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Oh, so try it with and without. I can do that, but it seems more of a > > security problem where you were trying two names instead of one. Do > > people like that? > > The nice thing about it is you can have any combination of people with > installation-wide access (create them as joeblow) and people with > one-database access (create them as joeblow@joesdatabase). A special > case for only the postgres user is much less flexible. Oh, yes, clearly a nice addition, but see below. > > It is easy to do, except for the fact we have to > > match pg_hba.conf with a username, though we could do the double-test > > there too, if that isn't too weird. > > It'd probably be better to first look at the flat-file copy of pg_shadow > to determine whether user or user@database is the form to use, and then > run through pg_hba.conf only once using the correct form. Otherwise > there are going to be all sorts of weird corner cases: user might match > a different pg_hba row than user@database does. Problem is that pg_shadow flat file _only_ has users with passwords. I do a btree search of that file, but I am not sure I want to add a dump of _all_ users just to allow this. Do we? > Also, if you do it this way then the substitution only has to be done in > one place: you can pass down the correct form to the backend, which'd > otherwise have to repeat the test to see which username is found. Yes, certainly a big win. What we _could_ do is to allow connections to template1 be unsuffixed by the dbname, but that makes everyone connecting to template1 have problems, and just seemed too weird. Ideas? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
On Wed, 2002-08-14 at 14:34, Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Oh, so try it with and without. I can do that, but it seems more of a > > security problem where you were trying two names instead of one. Do > > people like that? > > The nice thing about it is you can have any combination of people with > installation-wide access (create them as joeblow) and people with > one-database access (create them as joeblow@joesdatabase). A special > case for only the postgres user is much less flexible. > > > It is easy to do, except for the fact we have to > > match pg_hba.conf with a username, though we could do the double-test > > there too, if that isn't too weird. > > It'd probably be better to first look at the flat-file copy of pg_shadow > to determine whether user or user@database is the form to use, and then > run through pg_hba.conf only once using the correct form. Otherwise > there are going to be all sorts of weird corner cases: user might match > a different pg_hba row than user@database does. > > Also, if you do it this way then the substitution only has to be done in > one place: you can pass down the correct form to the backend, which'd > otherwise have to repeat the test to see which username is found. If there is a global 'user', then a database specific 'user@database' should be rejected shouldn't it? Otherwise we wind up with two potential 'user@database' users (globals users are really user@<each database>) but with a single ID.
On Wednesday 14 August 2002 02:38 pm, Bruce Momjian wrote: > Tom Lane wrote: > > The nice thing about it is you can have any combination of people with > > installation-wide access (create them as joeblow) and people with > > one-database access (create them as joeblow@joesdatabase). A special > > case for only the postgres user is much less flexible. > > Also, if you do it this way then the substitution only has to be done in > > one place: you can pass down the correct form to the backend, which'd > > otherwise have to repeat the test to see which username is found. > Yes, certainly a big win. What we _could_ do is to allow connections to > template1 be unsuffixed by the dbname, but that makes everyone > connecting to template1 have problems, and just seemed too weird. > Ideas? Appending '@template1' to unadorned usernames, and giving inherited rights across the installation to users with template1 rights? Then you have the unadorned 'lowen' becomes 'lowen@template1' -- but lowen@pari wouldn't have access to template1, right? Or am I misunderstanding the feature? -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Lamar Owen <lamar.owen@wgcr.org> writes:
> Appending '@template1' to unadorned usernames, and giving inherited rights
> across the installation to users with template1 rights? Then you have the
> unadorned 'lowen' becomes 'lowen@template1' -- but lowen@pari wouldn't have
> access to template1, right?
If not, standard things like "psql -l" won't work for lowen@pari. I don't
think we can get away with a scheme that depends on disallowing access
to template1 for most people.
It should also be noted that the whole point of this little project was
to do something *simple* ... checking access to some other database to
decide what we will allow is getting a bit far afield from simple.
regards, tom lane
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Problem is that pg_shadow flat file _only_ has users with passwords. I
> do a btree search of that file, but I am not sure I want to add a dump
> of _all_ users just to allow this. Do we?
Why not? Doesn't seem like a big penalty ...
regards, tom lane
On Wed, 14 Aug 2002, Tom Lane wrote: > Lamar Owen <lamar.owen@wgcr.org> writes: > > Appending '@template1' to unadorned usernames, and giving inherited rights > > across the installation to users with template1 rights? Then you have the > > unadorned 'lowen' becomes 'lowen@template1' -- but lowen@pari wouldn't have > > access to template1, right? > > If not, standard things like "psql -l" won't work for lowen@pari. I don't > think we can get away with a scheme that depends on disallowing access > to template1 for most people. > > It should also be noted that the whole point of this little project was > to do something *simple* ... checking access to some other database to > decide what we will allow is getting a bit far afield from simple. Hate to complicate things more, but back to a global username, say you have user "lowen" that should have access to all databases. What happens if there's already a lowen@somedb that's an unprivileged user. Assuming lowen is a db superuser, what happens in somedb? If there's a global user "lowen" and you try to create a lowen@somedb later, will it be allowed? One possible simplification would be to make the username the full username "lowen@somedb", "lowen", ... Right now we can create a "lowen@somedb" and it's a different user than "lowen" and we can already restrict a user to one database, can't we? Hmmm. Just checked and I guess not - I thought we had a record type of "user". Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net 56K Nationwide Dialup from $16.00/mo atPop4 Networking http://www.camping-usa.com http://www.cloudninegifts.com http://www.meanstreamradio.com http://www.unknown-artists.com ==========================================================================
On Wednesday 14 August 2002 03:04 pm, Tom Lane wrote:
> Lamar Owen <lamar.owen@wgcr.org> writes:
> > Appending '@template1' to unadorned usernames, and giving inherited
> > rights across the installation to users with template1 rights? Then you
> > have the unadorned 'lowen' becomes 'lowen@template1' -- but lowen@pari
> > wouldn't have access to template1, right?
> If not, standard things like "psql -l" won't work for lowen@pari. I don't
> think we can get away with a scheme that depends on disallowing access
> to template1 for most people.
Ok, maybe I'm really off base, but if I connect to database pari as
lowen@pari, isn't pg_database present there? I just tried here:
createdb pari
psql pari
Welcome to psql, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms \h for help with SQL commands \? for help on internal slash commands
\g or terminate with semicolon to execute query \q to quit
pari=# select datname from pg_database; datname
------------acs-testmaillabelstesting2template1template0pari
(6 rows)
So AFAICT if I were psql I would parse the unadorned lowen as
'lowen@template1' and connect to template1 if not otherwise specified. If
the fully qualified database user (FQDU) is present, parse the database name
out and connect to that database, then issue the SQL to do the -l or
whatever. The @pari would just override the normal default of template1,
right? So a 'psql -U lowen@pari -l ' would connect to database pari
(subject to permissions) and select datname from pg_database there.
What else am I missing, Tom? ISTM I don't need access to template1 --
although I wasn't necessarily suggesting eliminating that. I was more
suggesting:
lowen@pari has read access to those parts of template1 necessary for normal
functioning, full access (subject ot GRANT/REVOKE) of pari, and no access to
other databases;
lowen@template1 has access across the install (subject to GRANT/REVOKE, of
course). lowen@template1 = lowen (unadorned). That was the answer, I
thought, to the question Bruce had. There would be NO unadorned usernames
then, and no special handling EXCEPT of the template1 database, which is
already a special case.
Now, can we support the idea of 'postgres@pari' being a superuser for pari but
not for the rest of the install? Meaning no CREATE DATABASE right, as that
would require write access to template1? That's OK I believe, as I would
assume a 'tied to a database' superuser shouldn't be allowed to create a new
database to which he isn't going to have access..... The full ramifications
of this structure could prove interesting.
The supersuperuser 'postgres' becomes postgres@template1 -- template1 becoming
the consistent default database (for connecting as well as user membership).
As anything added to template1 becomes part of any subsequently added
databases, being a user in template1 becomes an installation-wide user.
And the user never really has to explicitly state @template1 -- they could
just leave off the @template1 and everything works as it does now.
Yes, there are complications, but not great ones, no?
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Problem is that pg_shadow flat file _only_ has users with passwords. I > > do a btree search of that file, but I am not sure I want to add a dump > > of _all_ users just to allow this. Do we? > > Why not? Doesn't seem like a big penalty ... Well, in most cases pg_pwd doesn't even get created unless someone has a password. We would be creating that file in all cases, or at least in all cases wher db_user_namespace is set, and again, that is a SIGHUP param, so you would need to make sure pg_pwd has the right contents if it was enabled during a sighup. Frankly, I would recommend a new file that just contains user names and is always created. We are basically heading down the road to complexity here. In fact, pg_hba.conf is just a microcosm of how we are going to handle pg_shadow matching. If we create dave@db1, then when dave tries to connect to db1, he comes in as dave@db1, but when he goes to connect to db2, if there is a plain 'dave', he will connect as 'dave' to db2, if possible. If people are OK with that, then I can easily push the double-testing down into the authentication system. It merely means testing the new pg_hba.conf USER column for two values, and pg_shadow for two values, but I would test with @db first. The double testing just seems strange to me because it splits the user namespace into two parts one with @ and one without, and conflicting user parts in the two namespaces do interact when @db does not match. That seems strange, but hey, if no one else thinks it is strange, it is easy to code. It is basically the same as testing pg_pwd, just doing it later in the code. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
On Wednesday 14 August 2002 03:29 pm, Vince Vielhaber wrote: > Hate to complicate things more, but back to a global username, say > you have user "lowen" that should have access to all databases. What > happens if there's already a lowen@somedb that's an unprivileged user. > Assuming lowen is a db superuser, what happens in somedb? If there's > a global user "lowen" and you try to create a lowen@somedb later, will > it be allowed? If the user 'lowen' is then expanded to 'lowen@template1' it would be stored that way -- and lowen@template1 is different from lowen@pari, for instance. The lowen@template1 user could be a superuser and lowen@pari might not -- but they become distinct users. Although I do understand the difficulty if the FQDU isn't stored in full in the appropriate places. So I guess the solution is that wherever a user name is to be stored, the fully qualified form must be used and checked against, with @template1 being a 'this user is everywhere' shorthand. But maybe I'm just misunderstanding the implementation. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Lamar Owen wrote: > On Wednesday 14 August 2002 03:29 pm, Vince Vielhaber wrote: > > Hate to complicate things more, but back to a global username, say > > you have user "lowen" that should have access to all databases. What > > happens if there's already a lowen@somedb that's an unprivileged user. > > Assuming lowen is a db superuser, what happens in somedb? If there's > > a global user "lowen" and you try to create a lowen@somedb later, will > > it be allowed? > > If the user 'lowen' is then expanded to 'lowen@template1' it would be stored > that way -- and lowen@template1 is different from lowen@pari, for instance. > The lowen@template1 user could be a superuser and lowen@pari might not -- but > they become distinct users. Although I do understand the difficulty if the > FQDU isn't stored in full in the appropriate places. So I guess the solution > is that wherever a user name is to be stored, the fully qualified form must > be used and checked against, with @template1 being a 'this user is > everywhere' shorthand. Yes, Vince is on to something with his quote above. If we have users with and without @, we get into the situation where users without @ may become users with @ when their usernames collide with existing user/db combinations already created. The point is that those two namespaces do collide and will cause confusion. Then you start to get into the situation where you always add @ and make @template1 a special case. However, remember that this flag can be turned on and off after initdb, so you need to be able to get in to set things up without great complexity _and_ the @template1 would not be passed in from the client, if for no other reason that the username is only 32 characters. It is the backend doing the flagging, and therefore the user can't say 'I am dave@templatge1' vs 'I am dave@connectdb'. This is how I got to the installuser hack in the first place. In fact, even the install user, typically 'postgres' has a problem because if you create 'postgres@db1', 'postgres' will have trouble connecing to db1 as themselves. I think we can live with one user who is special/global, but not more than one because of the confusion it would create. I can change the way this works, but we need a solution without holes. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
On Wed, 14 Aug 2002, Lamar Owen wrote: > On Wednesday 14 August 2002 03:29 pm, Vince Vielhaber wrote: > > Hate to complicate things more, but back to a global username, say > > you have user "lowen" that should have access to all databases. What > > happens if there's already a lowen@somedb that's an unprivileged user. > > Assuming lowen is a db superuser, what happens in somedb? If there's > > a global user "lowen" and you try to create a lowen@somedb later, will > > it be allowed? > > If the user 'lowen' is then expanded to 'lowen@template1' it would be stored > that way -- and lowen@template1 is different from lowen@pari, for instance. > The lowen@template1 user could be a superuser and lowen@pari might not -- but > they become distinct users. Although I do understand the difficulty if the > FQDU isn't stored in full in the appropriate places. So I guess the solution > is that wherever a user name is to be stored, the fully qualified form must > be used and checked against, with @template1 being a 'this user is > everywhere' shorthand. > > But maybe I'm just misunderstanding the implementation. I may be too, but what's wrong with just "lowen" being shorthand for 'this user is everywhere'? Does it also mean that we'd have a user postgres@template1? Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net 56K Nationwide Dialup from $16.00/mo atPop4 Networking http://www.camping-usa.com http://www.cloudninegifts.com http://www.meanstreamradio.com http://www.unknown-artists.com ==========================================================================
On Wednesday 14 August 2002 03:55 pm, Vince Vielhaber wrote: > On Wed, 14 Aug 2002, Lamar Owen wrote: > > If the user 'lowen' is then expanded to 'lowen@template1' it would be > > stored that way -- and lowen@template1 is different from lowen@pari, for > > But maybe I'm just misunderstanding the implementation. > > I may be too, but what's wrong with just "lowen" being shorthand for > 'this user is everywhere'? Does it also mean that we'd have a user > postgres@template1? WE could still use the form without @template1, but the backend would assume the @template1 user was being meant when the unqualified shorthand was used. So the former plain 'postgres' user could still be such to us, to client programs, etc, but the backend would assume that that meant postgres@template1 -- no namespace collision, and the special case is that anyone@template1 has the behavior the unadorned plain user now has. I do see Bruce's points, however. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
On Wednesday 14 August 2002 03:49 pm, Bruce Momjian wrote: > Lamar Owen wrote: > > On Wednesday 14 August 2002 03:29 pm, Vince Vielhaber wrote: > > > Hate to complicate things more, but back to a global username, say > > > you have user "lowen" that should have access to all databases. What > > places. So I guess the solution is that wherever a user name is to be > > stored, the fully qualified form must be used and checked against, with > > @template1 being a 'this user is everywhere' shorthand. > Yes, Vince is on to something with his quote above. > If we have users with and without @, we get into the situation where > users without @ may become users with @ when their usernames collide > with existing user/db combinations already created. The point is that > those two namespaces do collide and will cause confusion. But that's the exact problem I was trying to address -- as far as the backend is concerned, there isn't a user without @ -- the incoming connection from a user without @ is translated into a connection coming from user@template1. > Then you start to get into the situation where you always add @ and make > @template1 a special case. However, remember that this flag can be > turned on and off after initdb, so you need to be able to get in to set > things up without great complexity _and_ the @template1 would not be > passed in from the client, if for no other reason that the username is > only 32 characters. It is the backend doing the flagging, and therefore > the user can't say 'I am dave@templatge1' vs 'I am dave@connectdb'. Ok, how do I as a client specify the @dbname for the user? By the database I'm connecting to? That IS a wrinkle. But it does make sense, as lowen@pari won't be able to connect to any other database, right? So, where's this new notation going to get used, again? I must have misunderstood something. So, if we have a namespace collision -- then we have to make the implementation have the restriction that a global username can't exist as a database-specific username -- but two or more database-specific usernames can be the same. So, have a trigger on insertion of a user that checks for an existing user attached to template1 (again, for consistency -- installation wide templates are in template1 -- installation-wide users should be too) -- and then aborts the CREATE USER if so. > This is how I got to the installuser hack in the first place. In fact, > even the install user, typically 'postgres' has a problem because if you > create 'postgres@db1', 'postgres' will have trouble connecing to db1 as > themselves. I think we can live with one user who is special/global, but > not more than one because of the confusion it would create. If you say CREATE USER lowen@pari for the syntax, the create user trips the trigger, which checks for lowen@template1 and aborts if so. CREATE USER lowen@template1 does the same, checking for ANY user lowen. Namespace collision averted? CREATE USER lowen would be the same as CREATE USER lowen@connecteddb, so that the subsuperuser for connecteddb can just CREATE USER without qualifying -- the command line createdb could take the @dbname argument, splitting it out and connecting to the proper database. This has ramifications, I admit. And just saying that unqualified CREATE USER's should create the user@template1 introduces its own problems. > I can change the way this works, but we need a solution without holes. Trigger on the holes. But if I can't (or shouldn't) be able to specify the @dbname from the client, there is GOING to be a namespace collision if installation-wide users of ANY name are allowed (which is what you've already said -- just repeating for emphasis). Or we will have to forbid the postgres user from being reused -- trigger on CREATE USER and abort if user=postgres, I guess. Now as to the toggling of the feature -- what happens when you have lowen@pari and lowen@wgcr coexisting, and you turn off the feature? Which password becomes valid for the resultant singular user lowen? IMHO, if two or more users of the same name occurs, then you shouldn't be able to turn the feature off. I know you've already put alot of work into this, Bruce. But what if the feature isn't toggled, but always there, just waiting to be exploited by CREATE USER user@db, with the default CREATE USER always putting the user into association with the currently connected database? Is there bad overhead involved? Is it something that could break installations not using the feature? Or should CREATE USER with an unqualified username default to @template1 (what I originally thought it should). -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Lamar Owen <lamar.owen@wgcr.org> writes:
> So the former plain 'postgres' user could still be such to us, to client
> programs, etc, but the backend would assume that that meant
> postgres@template1 -- no namespace collision, and the special case is that
> anyone@template1 has the behavior the unadorned plain user now has.
The trouble with that scheme is that there is zero interoperability
between the plain-vanilla mode (postgres is postgres in pg_shadow) and
the @-mode (postgres is postgres@template1 in pg_shadow). Flip the
configuration switch, in either direction, and you can't log in anymore.
We'd almost have to make it a frozen-at-initdb setting so that initdb
would know which form to put into pg_shadow for the superuser, and so
that entry wouldn't break thereafter.
The reason I like the "lowen" vs "lowen@somedb" pattern is that
database-global users can log in the same way whether the feature is
turned on or not; this eliminates the getting-started problem, as well
as the likelihood of shooting yourself in the foot.
It is true that if you have a global user lowen you'd want to avoid
creating any local users lowen@somedb, and that the existing code
wouldn't be able to enforce that. We could possibly add a few lines
to CREATE USER to warn about this mistake. (It should be a warning not
an error, since if you have no intention of ever using the @-feature
then there's no reason to restrict your choice of usernames.)
regards, tom lane
Bruce Momjian writes: > OK, what I didn't want to do we to over-complexify That's reasonable, but not when you break other things along the way that were themselves meant to decomplexify things. > something that is for only a few users. If it's only for a few users, please send private patches to them. Face it, it's not going to happen. It's going to be in the release notes, everyone's going to see it, and there's going to be a Slashdot thread about how "they" broke the password files. So let's design a feature for everyone. -- Peter Eisentraut peter_e@gmx.net
OK, I have a new idea. Seems most don't like that 'postgres' is a special user in this context. How about if we just document that they have to create a postgres@template1 user before flipping the switch. That way, there is no special user, no PG_INSTALLER file, and no double-tests for user names. It doesn't give us a global user, but frankly, it seems that such a system is never going to work reliably. Trying to prevent namespace conflicts by checking for users without @ that may match will make @ a special character in the user namespace, and people won't like that. --------------------------------------------------------------------------- Tom Lane wrote: > Lamar Owen <lamar.owen@wgcr.org> writes: > > So the former plain 'postgres' user could still be such to us, to client > > programs, etc, but the backend would assume that that meant > > postgres@template1 -- no namespace collision, and the special case is that > > anyone@template1 has the behavior the unadorned plain user now has. > > The trouble with that scheme is that there is zero interoperability > between the plain-vanilla mode (postgres is postgres in pg_shadow) and > the @-mode (postgres is postgres@template1 in pg_shadow). Flip the > configuration switch, in either direction, and you can't log in anymore. > We'd almost have to make it a frozen-at-initdb setting so that initdb > would know which form to put into pg_shadow for the superuser, and so > that entry wouldn't break thereafter. > > The reason I like the "lowen" vs "lowen@somedb" pattern is that > database-global users can log in the same way whether the feature is > turned on or not; this eliminates the getting-started problem, as well > as the likelihood of shooting yourself in the foot. > > It is true that if you have a global user lowen you'd want to avoid > creating any local users lowen@somedb, and that the existing code > wouldn't be able to enforce that. We could possibly add a few lines > to CREATE USER to warn about this mistake. (It should be a warning not > an error, since if you have no intention of ever using the @-feature > then there's no reason to restrict your choice of usernames.) > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> How about if we just document that they have to create a
> postgres@template1 user before flipping the switch. That way, there is
> no special user, no PG_INSTALLER file, and no double-tests for user
> names.
... and no useful superuser account; if you can't connect to anything
except template1 then you ain't much of a superuser.
To get around that you'd have to create postgres@db1, postgres@db2,
postgres@db3, etc etc. This would be a huge pain in the neck; I think
it'd render the scheme impractical. (Keep in mind that anybody who'd be
interested in this feature at all has probably got quite a number of
databases to contend with.)
regards, tom lane
On Wed, 14 Aug 2002, Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > I have no personal preference between period and @ or whatever. See if > > you can get some other votes for @ because most left @ when the ORDER BY > > idea came up from Marc. > > FWIW, I still lean to username@database, so I think we're roughly at a > tie. It would be good to get more votes ... Seeing as this is rumbling on I'll throw in my fraction of a vote. I too like the user@database form, partly because it 'reads'. On the other hand I can see the the reasons to like database.user and it does match the style of database.schema.object. Unfortunately for this second form, as '.' is a valid character in a database name then I can see this causing problems, especially with the behind the scenes combination of the two names. I don't see this problem with the '@' form because I can't see that character being used in a 'unqualified' user name. Hmmm...not sure that makes a terribly good arguement for my vote for 'user@db', is there a third choice for us confused folks to go for? A compromise: database@username ? [BTW, I did check and '@' seems to be a valid character in database and user names.] -- Nigel J. Andrews Director --- Logictree Systems Limited Computer Consultants
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > How about if we just document that they have to create a > > postgres@template1 user before flipping the switch. That way, there is > > no special user, no PG_INSTALLER file, and no double-tests for user > > names. > > ... and no useful superuser account; if you can't connect to anything > except template1 then you ain't much of a superuser. > > To get around that you'd have to create postgres@db1, postgres@db2, > postgres@db3, etc etc. This would be a huge pain in the neck; I think > it'd render the scheme impractical. (Keep in mind that anybody who'd be > interested in this feature at all has probably got quite a number of > databases to contend with.) Yes, I hear you, but that brings us around full-circle to the original patch with one super-user who is the install user. I don't know where else to go with the patch at this point. I think increasing the number of 'global' users is polluting the namespace too much, and having none seems to be unappealing. This is why I am back to just the install user. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I don't know where else to go with the patch at this point. I think
> increasing the number of 'global' users is polluting the namespace too
> much,
Why? If the installation needs N global users, then it needs N global
users; who are you to make that value judgment for them?
In practice I think an installation that's using this feature is going
to have a pretty small number of global users, and so the issue of
collisions with local usernames isn't really as big as it's been painted
in this thread. We could ignore that issue (except for documenting it)
and have a perfectly serviceable feature.
But I don't think it's a wise idea to design the thing in a way that
makes it impossible to have more than one global user.
If you don't like including all the pg_shadow entries in the flat file
(though I really don't see any problem with that), could we replace
PG_INSTALL with a pg_global_users config file that lists the global user
names? I think it would be good enough to let this be hand-maintained,
with initdb initializing it to contain the install user's name.
regards, tom lane
On Wed, 14 Aug 2002, Bruce Momjian wrote: > Tom Lane wrote: > > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > > How about if we just document that they have to create a > > > postgres@template1 user before flipping the switch. That way, there is > > > no special user, no PG_INSTALLER file, and no double-tests for user > > > names. > > > > ... and no useful superuser account; if you can't connect to anything > > except template1 then you ain't much of a superuser. > > > > To get around that you'd have to create postgres@db1, postgres@db2, > > postgres@db3, etc etc. This would be a huge pain in the neck; I think > > it'd render the scheme impractical. (Keep in mind that anybody who'd be > > interested in this feature at all has probably got quite a number of > > databases to contend with.) > > Yes, I hear you, but that brings us around full-circle to the original > patch with one super-user who is the install user. > > I don't know where else to go with the patch at this point. I think > increasing the number of 'global' users is polluting the namespace too > much, and having none seems to be unappealing. This is why I am back to > just the install user. I wouldn't be in favor of that. Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net 56K Nationwide Dialup from $16.00/mo atPop4 Networking http://www.camping-usa.com http://www.cloudninegifts.com http://www.meanstreamradio.com http://www.unknown-artists.com ==========================================================================
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > I don't know where else to go with the patch at this point. I think > > increasing the number of 'global' users is polluting the namespace too > > much, > > Why? If the installation needs N global users, then it needs N global > users; who are you to make that value judgment for them? > > In practice I think an installation that's using this feature is going > to have a pretty small number of global users, and so the issue of > collisions with local usernames isn't really as big as it's been painted > in this thread. We could ignore that issue (except for documenting it) > and have a perfectly serviceable feature. The original idea was that Marc wanted people who could create their own users for their own databases. If we make the creation of global users too easy, all of a sudden people don't have control over their db usernames because they have to avoid all the global user names already defined. By adding multiple global users, it is diluting the usefulness of the feature. I suppose a pg_global_users file would be a compromise because only the admin could actually add people to that file. If it was more automatic, like writing pg_shadow, someone could create a user without an @ and block access for other users to other database, which is bad. I still don't like the fact that people think they have control over their db namespace, when they really don't, but no one else seems to see that as a problem. The namespace conflicts just yell of poor design. OK, I have another idea. What if we make global users end with an @, so dave@ is a global user. We can easily check for that in the postmaster and not append the dbname. I know it makes @ a special character, but considering the problem of namespace collision, it seems better than what we have now. We could add the install user too if we wish, or just tell them to make sure they add a user@ before turning on the feature. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
pgman@candle.pha.pa.us (Bruce Momjian) wrote: > Tom Lane wrote: >> Bruce Momjian <pgman@candle.pha.pa.us> writes: >> > I don't know where else to go with the patch at this point. I >> > think increasing the number of 'global' users is polluting the >> > namespace too much, >> >> Why? If the installation needs N global users, then it needs N >> global users; who are you to make that value judgment for them? >> >> In practice I think an installation that's using this feature is >> going to have a pretty small number of global users, and so the issue >> of collisions with local usernames isn't really as big as it's been >> painted in this thread. We could ignore that issue (except for >> documenting it) and have a perfectly serviceable feature. > > The original idea was that Marc wanted people who could create their > own users for their own databases. If we make the creation of global > users too easy, all of a sudden people don't have control over their > db usernames because they have to avoid all the global user names > already defined. By adding multiple global users, it is diluting the > usefulness of the feature. > Maybe I am missing something here but shouldnt db access really be part of the privileges system? If all we are talking about is a quick hack until this can be implemented correctly, what is the concern with having so much functionality in the hack? Why does it matter what the actual usernames can or cant be? For example you could just make everyone with a username NNNNNN@dbname (where N's are int) local accounts and then leave everything else alone. The only issue I could see with something like this would be that someone trying to use this hack wont be able to give their users names like pudgy@dbname, but who cares? I mean if you are giving access to a bunch of developers, how is it going to affect them if you tell them to login with 123456@yourdb instead of jsmith@yourdb? If they cant remember it or something maybe they can write it down? I dunno...
Hannu Krosing wrote: > What about functions > > 1. split(text,text,int) returns text > > 2. split(text,text) returns text[] > > and why not > > 3. split(text,text,text) returns text > > which returns text from $1 delimited by $2 and $3 Given the time remaining before beta, I'll be happy just to get #1 done. I can see the utility of #2 (or perhaps even a table function which breaks the string into individual rows). I'm not sure I understand #3. I am concerned about the name though -- only in that there are usually objections raised to function names that are too likely to conflict with user created function names. But "split" is good from the standpoint that it is used in other languages, so people should find it familiar. Anyone have comments on the name? Joe
Joe Conway wrote: > > Hannu Krosing wrote: > > What about functions > > > > 1. split(text,text,int) returns text > > > > 2. split(text,text) returns text[] > > > > and why not > > > > 3. split(text,text,text) returns text > > > > which returns text from $1 delimited by $2 and $3 > > Given the time remaining before beta, I'll be happy just to get #1 done. > > I can see the utility of #2 (or perhaps even a table function which > breaks the string into individual rows). I'm not sure I understand #3. > > I am concerned about the name though -- only in that there are usually > objections raised to function names that are too likely to conflict with > user created function names. But "split" is good from the standpoint > that it is used in other languages, so people should find it familiar. > > Anyone have comments on the name? Actually, I've been wondering if it wouldn't be a good idea with schemas coming to think now about how to divide up namespaces for all sorts of things, including PostgreSQL's built in functions, the contrib code, etc. I think a naming scheme with which both PostgreSQL and the community would comply, a la Java's reverse DNS scheme for namespaces would be neat. So when a database is installed, the following schemas are automatically created: org.postgresql.system <- System tables and core functions org.postgresql.text <- Text related functions org.postgresql.math <- Math related functions org.postgresql.fts <- Full-Text schema or perhaps: org.postgresql.contrib.fts <- Full-Text schema etc. I don't even know if "." is allowed in the schema names, but you get the idea. Then, a users search_path (or whatever it's called, I haven't used the development version in a while), would be the equivalent of Java's "import" statement, or C++'s "using" statement. So "split" would be a function in the org.postgresql.text schema. How about them apples? If this is an insane idea, its 3:32 A.M. my time ;-) Mike Mascari mascarm@mascari.com > > Joe
Mike Mascari <mascarm@mascari.com> writes:
> I don't even know if "." is allowed in the schema names,
It isn't, and we couldn't invent such a scheme without seriously
diverging from SQL compliance: the next naming level up from schemas is
reserved for catalogs (think databases). I don't know that we'll ever
support cross-database access, but we shouldn't foreclose the
possibility in pursuit of a naming scheme that doesn't really add very
much value.
You could possibly fake it with schema names like org_postgresql_foo,
but I can't get very excited about that ...
regards, tom lane
On Sun, Aug 11, 2002 at 11:12:57AM -0400, Tom Lane wrote: > > Not solved yet. And it's just a matter of time until we run into it with > > the main parser grammar file as well. > > Yeah, I've been worrying about that too. Any idea how close we are to > trouble in the main grammar? No idea. The ecpg grammar in the main tree has about 530 rules, while my actual version is at nearly 550. The main grammar should be at about 440. So there's some room left. > Plan C would be to devote some work to minimizing the number of states > in the main grammar (I assume it's number of states that's the problem). > I doubt anyone's ever tried, so there might be enough low-hanging fruit > to get ecpg off the hook for awhile. Actually I already ate the really low-hanging fruit. :-) I did spend some time to reduce the states, albeit surely not to the extent possible, but still it will mean quite some work I'm afraid. Michael P.S.: No repsonse by bison upstream yet, but I think he's on vacation this week. -- Michael Meskes Michael@Fam-Meskes.De Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
OK, no one complained/commented on my idea of having global users have a
trailing '@', so here is a patch that implements that. It has the
advantages of:
no special install user (create global user before enabling feature)
no /data/PG_INSTALLER file
allows multiple global users to be easily added
no namespace collisions because globals have a trailing @
easy for postmaster to recognize global users
no double-user lookups of pg_pwd changes
very small patch footprint
The only downside is that it treats '@' as a special character when it
is enabled, but frankly, because we are appending @dbname anyway, having
'@' as a special character in that case makes sense.
Comments?
---------------------------------------------------------------------------
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > > I don't know where else to go with the patch at this point. I think
> > > increasing the number of 'global' users is polluting the namespace too
> > > much,
> >
> > Why? If the installation needs N global users, then it needs N global
> > users; who are you to make that value judgment for them?
> >
> > In practice I think an installation that's using this feature is going
> > to have a pretty small number of global users, and so the issue of
> > collisions with local usernames isn't really as big as it's been painted
> > in this thread. We could ignore that issue (except for documenting it)
> > and have a perfectly serviceable feature.
>
> The original idea was that Marc wanted people who could create their own
> users for their own databases. If we make the creation of global users
> too easy, all of a sudden people don't have control over their db
> usernames because they have to avoid all the global user names already
> defined. By adding multiple global users, it is diluting the usefulness
> of the feature.
>
> I suppose a pg_global_users file would be a compromise because only the
> admin could actually add people to that file. If it was more automatic,
> like writing pg_shadow, someone could create a user without an @ and
> block access for other users to other database, which is bad.
>
> I still don't like the fact that people think they have control over
> their db namespace, when they really don't, but no one else seems to see
> that as a problem. The namespace conflicts just yell of poor design.
>
> OK, I have another idea. What if we make global users end with an @, so
> dave@ is a global user. We can easily check for that in the postmaster
> and not append the dbname. I know it makes @ a special character, but
> considering the problem of namespace collision, it seems better than
> what we have now. We could add the install user too if we wish, or just
> tell them to make sure they add a user@ before turning on the feature.
>
> --
> Bruce Momjian | http://candle.pha.pa.us
> pgman@candle.pha.pa.us | (610) 359-1001
> + If your life is a hard drive, | 13 Roberts Road
> + Christ can be your backup. | Newtown Square, Pennsylvania 19073
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Index: doc/src/sgml/runtime.sgml
===================================================================
RCS file: /cvsroot/pgsql-server/doc/src/sgml/runtime.sgml,v
retrieving revision 1.125
diff -c -r1.125 runtime.sgml
*** doc/src/sgml/runtime.sgml 15 Aug 2002 14:26:15 -0000 1.125
--- doc/src/sgml/runtime.sgml 15 Aug 2002 15:32:29 -0000
***************
*** 1191,1196 ****
--- 1191,1211 ----
</varlistentry>
<varlistentry>
+ <term><varname>DB_USER_NAMESPACE</varname> (<type>boolean</type>)</term>
+ <listitem>
+ <para>
+ Appends <literal>@</> and the database name to the user name when
+ connecting to the database. This allows per-database users.
+ User names ending with <literal>@</> are considered global and may
+ connect to any database. It is recommended you create at least one
+ global user, e.g. <literal>postgres@</>, before enabling this feature.
+ Also, when creating user names containing <literal>@</>, you will need
+ to quote the user name.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
<indexterm>
<primary>deadlock</primary>
<secondary>timeout</secondary>
Index: src/backend/libpq/auth.c
===================================================================
RCS file: /cvsroot/pgsql-server/src/backend/libpq/auth.c,v
retrieving revision 1.82
diff -c -r1.82 auth.c
*** src/backend/libpq/auth.c 20 Jun 2002 20:29:28 -0000 1.82
--- src/backend/libpq/auth.c 15 Aug 2002 15:32:30 -0000
***************
*** 117,123 ****
version, PG_KRB4_VERSION);
return STATUS_ERROR;
}
! if (strncmp(port->user, auth_data.pname, SM_USER) != 0)
{
elog(LOG, "pg_krb4_recvauth: name \"%s\" != \"%s\"",
port->user, auth_data.pname);
--- 117,123 ----
version, PG_KRB4_VERSION);
return STATUS_ERROR;
}
! if (strncmp(port->user, auth_data.pname, SM_DATABASE_USER) != 0)
{
elog(LOG, "pg_krb4_recvauth: name \"%s\" != \"%s\"",
port->user, auth_data.pname);
***************
*** 290,296 ****
}
kusername = pg_an_to_ln(kusername);
! if (strncmp(port->user, kusername, SM_USER))
{
elog(LOG, "pg_krb5_recvauth: user name \"%s\" != krb5 name \"%s\"",
port->user, kusername);
--- 290,296 ----
}
kusername = pg_an_to_ln(kusername);
! if (strncmp(port->user, kusername, SM_DATABASE_USER))
{
elog(LOG, "pg_krb5_recvauth: user name \"%s\" != krb5 name \"%s\"",
port->user, kusername);
Index: src/backend/postmaster/postmaster.c
===================================================================
RCS file: /cvsroot/pgsql-server/src/backend/postmaster/postmaster.c,v
retrieving revision 1.283
diff -c -r1.283 postmaster.c
*** src/backend/postmaster/postmaster.c 10 Aug 2002 20:29:18 -0000 1.283
--- src/backend/postmaster/postmaster.c 15 Aug 2002 15:32:34 -0000
***************
*** 116,122 ****
sigset_t UnBlockSig,
BlockSig,
AuthBlockSig;
-
#else
int UnBlockSig,
BlockSig,
--- 116,121 ----
***************
*** 191,196 ****
--- 190,197 ----
bool HostnameLookup; /* for ps display */
bool ShowPortNumber;
bool Log_connections = false;
+ bool Db_user_namespace = false;
+
/* Startup/shutdown state */
static pid_t StartupPID = 0,
***************
*** 1161,1166 ****
--- 1162,1177 ----
if (port->user[0] == '\0')
elog(FATAL, "no PostgreSQL user name specified in startup packet");
+ /* Append database name for per-db user namespace, exclude global users. */
+ if (Db_user_namespace && strlen(port->user) > 0 &&
+ port->user[strlen(port->user)-1] != '@')
+ {
+ char hold_user[SM_DATABASE_USER];
+ snprintf(hold_user, SM_DATABASE_USER, "%s@%s", port->user,
+ port->database);
+ strcpy(port->user, hold_user);
+ }
+
/*
* If we're going to reject the connection due to database state, say
* so now instead of wasting cycles on an authentication exchange.
***************
*** 2587,2597 ****
if (FindExec(fullprogname, argv[0], "postmaster") < 0)
return false;
! filename = palloc(strlen(DataDir) + 20);
sprintf(filename, "%s/postmaster.opts", DataDir);
! fp = fopen(filename, "w");
! if (fp == NULL)
{
postmaster_error("cannot create file %s: %s",
filename, strerror(errno));
--- 2598,2607 ----
if (FindExec(fullprogname, argv[0], "postmaster") < 0)
return false;
! filename = palloc(strlen(DataDir) + 17);
sprintf(filename, "%s/postmaster.opts", DataDir);
! if ((fp = fopen(filename, "w")) == NULL)
{
postmaster_error("cannot create file %s: %s",
filename, strerror(errno));
Index: src/backend/utils/misc/guc.c
===================================================================
RCS file: /cvsroot/pgsql-server/src/backend/utils/misc/guc.c,v
retrieving revision 1.82
diff -c -r1.82 guc.c
*** src/backend/utils/misc/guc.c 15 Aug 2002 02:51:26 -0000 1.82
--- src/backend/utils/misc/guc.c 15 Aug 2002 15:32:42 -0000
***************
*** 483,488 ****
--- 483,492 ----
{ "transform_null_equals", PGC_USERSET }, &Transform_null_equals,
false, NULL, NULL
},
+ {
+ { "db_user_namespace", PGC_SIGHUP }, &Db_user_namespace,
+ false, NULL, NULL
+ },
{
{ NULL, 0 }, NULL, false, NULL, NULL
Index: src/backend/utils/misc/postgresql.conf.sample
===================================================================
RCS file: /cvsroot/pgsql-server/src/backend/utils/misc/postgresql.conf.sample,v
retrieving revision 1.44
diff -c -r1.44 postgresql.conf.sample
*** src/backend/utils/misc/postgresql.conf.sample 12 Aug 2002 00:36:12 -0000 1.44
--- src/backend/utils/misc/postgresql.conf.sample 15 Aug 2002 15:32:42 -0000
***************
*** 113,119 ****
#
# Message display
#
-
#server_min_messages = notice # Values, in order of decreasing detail:
# debug5, debug4, debug3, debug2, debug1,
# info, notice, warning, error, log, fatal,
--- 113,118 ----
***************
*** 201,203 ****
--- 200,203 ----
#sql_inheritance = true
#transform_null_equals = false
#statement_timeout = 0 # 0 is disabled
+ #db_user_namespace = false
Index: src/include/libpq/libpq-be.h
===================================================================
RCS file: /cvsroot/pgsql-server/src/include/libpq/libpq-be.h,v
retrieving revision 1.32
diff -c -r1.32 libpq-be.h
*** src/include/libpq/libpq-be.h 20 Jun 2002 20:29:49 -0000 1.32
--- src/include/libpq/libpq-be.h 15 Aug 2002 15:32:43 -0000
***************
*** 59,65 ****
ProtocolVersion proto;
char database[SM_DATABASE + 1];
! char user[SM_USER + 1];
char options[SM_OPTIONS + 1];
char tty[SM_TTY + 1];
char auth_arg[MAX_AUTH_ARG];
--- 59,65 ----
ProtocolVersion proto;
char database[SM_DATABASE + 1];
! char user[SM_DATABASE_USER + 1];
char options[SM_OPTIONS + 1];
char tty[SM_TTY + 1];
char auth_arg[MAX_AUTH_ARG];
***************
*** 72,78 ****
SSL *ssl;
X509 *peer;
char peer_dn[128 + 1];
! char peer_cn[SM_USER + 1];
unsigned long count;
#endif
} Port;
--- 72,78 ----
SSL *ssl;
X509 *peer;
char peer_dn[128 + 1];
! char peer_cn[SM_DATABASE_USER + 1];
unsigned long count;
#endif
} Port;
Index: src/include/libpq/pqcomm.h
===================================================================
RCS file: /cvsroot/pgsql-server/src/include/libpq/pqcomm.h,v
retrieving revision 1.65
diff -c -r1.65 pqcomm.h
*** src/include/libpq/pqcomm.h 12 Aug 2002 14:35:26 -0000 1.65
--- src/include/libpq/pqcomm.h 15 Aug 2002 15:32:43 -0000
***************
*** 114,119 ****
--- 114,121 ----
#define SM_DATABASE 64
/* SM_USER should be the same size as the others. bjm 2002-06-02 */
#define SM_USER 32
+ /* We append database name if db_user_namespace true. */
+ #define SM_DATABASE_USER (SM_DATABASE+SM_USER)
#define SM_OPTIONS 64
#define SM_UNUSED 64
#define SM_TTY 64
***************
*** 124,135 ****
--- 126,139 ----
{
ProtocolVersion protoVersion; /* Protocol version */
char database[SM_DATABASE]; /* Database name */
+ /* Db_user_namespace appends dbname */
char user[SM_USER]; /* User name */
char options[SM_OPTIONS]; /* Optional additional args */
char unused[SM_UNUSED]; /* Unused */
char tty[SM_TTY]; /* Tty for debug output */
} StartupPacket;
+ extern bool Db_user_namespace;
/* These are the authentication requests sent by the backend. */
On Thu, 15 Aug 2002, Bruce Momjian wrote: > > OK, no one complained/commented on my idea of having global users have a > trailing '@', so here is a patch that implements that. It has the > advantages of: Probably because not everyone saw it. I know I didn't. This entire issue is growing more and more complex. How about a configure item to not even compile it in? Or better yet, a configure item to put it there with the default off. Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net 56K Nationwide Dialup from $16.00/mo atPop4 Networking http://www.camping-usa.com http://www.cloudninegifts.com http://www.meanstreamradio.com http://www.unknown-artists.com ==========================================================================
Vince, you were in the CC, and it went to hackers:Message 772/835 Bruce Momjian
Aug 14, 2002 08:30:47 pm -0400Subject: Re: [HACKERS] Open 7.3 itemsTo: Tom Lane
<tgl@sss.pgh.pa.us>Date:Wed, 14 Aug 2002 20:30:47 -0400 (EDT)cc: Lamar Owen <lamar.owen@wgcr.org>, Vince Vielhaber
<vev@michvhf.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>X-Virus-Scanned: by AMaViS
new-20020517Precedence:bulkSender: pgsql-hackers-owner@postgresql.orgX-Virus-Scanned: by AMaViS new-20020517
---------------------------------------------------------------------------
Vince Vielhaber wrote:
> On Thu, 15 Aug 2002, Bruce Momjian wrote:
>
> >
> > OK, no one complained/commented on my idea of having global users have a
> > trailing '@', so here is a patch that implements that. It has the
> > advantages of:
>
> Probably because not everyone saw it. I know I didn't. This entire
> issue is growing more and more complex. How about a configure item
> to not even compile it in? Or better yet, a configure item to put
> it there with the default off.
>
> Vince.
> --
> ==========================================================================
> Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net
> 56K Nationwide Dialup from $16.00/mo at Pop4 Networking
> http://www.camping-usa.com http://www.cloudninegifts.com
> http://www.meanstreamradio.com http://www.unknown-artists.com
> ==========================================================================
>
>
>
>
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073
Vince Vielhaber wrote: > On Thu, 15 Aug 2002, Bruce Momjian wrote: > > > > > OK, no one complained/commented on my idea of having global users have a > > trailing '@', so here is a patch that implements that. It has the > > advantages of: > > Probably because not everyone saw it. I know I didn't. This entire > issue is growing more and more complex. How about a configure item > to not even compile it in? Or better yet, a configure item to put > it there with the default off. I think I am prety close, and I don't see a configure flag as any better than a GUC option that is off by default. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
On Thu, 15 Aug 2002, Bruce Momjian wrote: > > Vince, you were in the CC, and it went to hackers: Oh, I'm not saying I didn't get it, I'm saying I didn't see it in the message. It looked as if you were only replying to Tom so after reading the jist of it I moved on. When you included it a little while ago I wondered what you were referring to so I read the whole thing more carefully and realized that I missed the end. Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net 56K Nationwide Dialup from $16.00/mo atPop4 Networking http://www.camping-usa.com http://www.cloudninegifts.com http://www.meanstreamradio.com http://www.unknown-artists.com ==========================================================================
On Thu, 15 Aug 2002, Bruce Momjian wrote: > Vince Vielhaber wrote: > > On Thu, 15 Aug 2002, Bruce Momjian wrote: > > > > > > > > OK, no one complained/commented on my idea of having global users have a > > > trailing '@', so here is a patch that implements that. It has the > > > advantages of: > > > > Probably because not everyone saw it. I know I didn't. This entire > > issue is growing more and more complex. How about a configure item > > to not even compile it in? Or better yet, a configure item to put > > it there with the default off. > > I think I am prety close, and I don't see a configure flag as any better > than a GUC option that is off by default. But how many people would even use it? I can't see adding the bloat unnecessarily and risking it accidently being turned on. Am I wrong and really alot of people actually want/need this? Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net 56K Nationwide Dialup from $16.00/mo atPop4 Networking http://www.camping-usa.com http://www.cloudninegifts.com http://www.meanstreamradio.com http://www.unknown-artists.com ==========================================================================
Vince Vielhaber wrote: > On Thu, 15 Aug 2002, Bruce Momjian wrote: > > > Vince Vielhaber wrote: > > > On Thu, 15 Aug 2002, Bruce Momjian wrote: > > > > > > > > > > > OK, no one complained/commented on my idea of having global users have a > > > > trailing '@', so here is a patch that implements that. It has the > > > > advantages of: > > > > > > Probably because not everyone saw it. I know I didn't. This entire > > > issue is growing more and more complex. How about a configure item > > > to not even compile it in? Or better yet, a configure item to put > > > it there with the default off. > > > > I think I am prety close, and I don't see a configure flag as any better > > than a GUC option that is off by default. > > But how many people would even use it? I can't see adding the bloat > unnecessarily and risking it accidently being turned on. Am I wrong > and really alot of people actually want/need this? Well, the demand seems to be larger than I thought, considering the number of people who have chimed in and want certain features, like multiple global users. I see this being using more by ISP's and universities that need better user/db partitioning. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
On Thu, 15 Aug 2002, Bruce Momjian wrote: > Vince Vielhaber wrote: > > On Thu, 15 Aug 2002, Bruce Momjian wrote: > > > > > Vince Vielhaber wrote: > > > > On Thu, 15 Aug 2002, Bruce Momjian wrote: > > > > > > > > > > > > > > OK, no one complained/commented on my idea of having global users have a > > > > > trailing '@', so here is a patch that implements that. It has the > > > > > advantages of: > > > > > > > > Probably because not everyone saw it. I know I didn't. This entire > > > > issue is growing more and more complex. How about a configure item > > > > to not even compile it in? Or better yet, a configure item to put > > > > it there with the default off. > > > > > > I think I am prety close, and I don't see a configure flag as any better > > > than a GUC option that is off by default. > > > > But how many people would even use it? I can't see adding the bloat > > unnecessarily and risking it accidently being turned on. Am I wrong > > and really alot of people actually want/need this? > > Well, the demand seems to be larger than I thought, considering the > number of people who have chimed in and want certain features, like > multiple global users. I see this being using more by ISP's and > universities that need better user/db partitioning. I don't know that concern over a possible limited number of global users is directly proportional to the desire for the feature. Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net 56K Nationwide Dialup from $16.00/mo atPop4 Networking http://www.camping-usa.com http://www.cloudninegifts.com http://www.meanstreamradio.com http://www.unknown-artists.com ==========================================================================
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> + /* We append database name if db_user_namespace true. */
> + #define SM_DATABASE_USER (SM_DATABASE+SM_USER)
Is this calculation correct? I'd think you'd need at least one more
character to allow for the "@". And I'm not sure about whether trailing
nulls are or need to be counted. There seem to be some places in your
patch where things are dimensioned SM_DATABASE_USER and some where it's
SM_DATABASE_USER+1; why the inconsistency, and which is right?
Other than getting the array sizes right, it does look like a nice
patch; very small, which is what I'd hoped for. The notion of having to
say "postgres@" still seems kinda ugly, but given the simplicity of the
patch I'm willing to live with that.
regards, tom lane
On Thu, 15 Aug 2002, Tom Lane wrote: > Other than getting the array sizes right, it does look like a nice > patch; very small, which is what I'd hoped for. The notion of having to > say "postgres@" still seems kinda ugly, but given the simplicity of the > patch I'm willing to live with that. Going from postgres to postgres@ ??? I don't care how simple the patch is, I'd rather it was configurable to keep it out completely. That's not just ugly, that's coyote ugly! Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net 56K Nationwide Dialup from $16.00/mo atPop4 Networking http://www.camping-usa.com http://www.cloudninegifts.com http://www.meanstreamradio.com http://www.unknown-artists.com ==========================================================================
On Thursday 15 August 2002 11:54 am, Bruce Momjian wrote: > OK, no one complained/commented on my idea of having global users have a > trailing '@', so here is a patch that implements that. It has the > advantages of: As it's substantially the same as user@template1, I am of course OK with it. :-) Easier to type than user@template1, too. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Vince Vielhaber <vev@michvhf.com> writes:
> Going from postgres to postgres@ ??? I don't care how simple the patch
> is, I'd rather it was configurable to keep it out completely. That's
> not just ugly, that's coyote ugly!
Yeah, but it doesn't affect you unless you turn on the GUC parameter.
Most people will never even know this code is there.
regards, tom lane
On Thu, 15 Aug 2002, Tom Lane wrote: > Vince Vielhaber <vev@michvhf.com> writes: > > Going from postgres to postgres@ ??? I don't care how simple the patch > > is, I'd rather it was configurable to keep it out completely. That's > > not just ugly, that's coyote ugly! > > Yeah, but it doesn't affect you unless you turn on the GUC parameter. > Most people will never even know this code is there. But it doesn't need to affect anyone, even if it's enabled. Isn't the lack of an @ just as good as an @ at the end of the username? Gets rid of the ugliness and won't break things if it's suddenly enabled. Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net 56K Nationwide Dialup from $16.00/mo atPop4 Networking http://www.camping-usa.com http://www.cloudninegifts.com http://www.meanstreamradio.com http://www.unknown-artists.com ==========================================================================
Vince Vielhaber <vev@michvhf.com> writes:
> But it doesn't need to affect anyone, even if it's enabled. Isn't
> the lack of an @ just as good as an @ at the end of the username?
No, because there isn't any @ in the incoming connection request in the
normal-user case: just a user name and a database name, which *we* have
to assemble into user@database.
We can't really expect the users to do this for us (give user@database
as their full user name). There are a number of reasons why I don't
wanna do that, but the real showstopper is that the username field of
the connection request packet is only 32 bytes wide, and we cannot
enlarge it without a protocol breakage. Fitting "user@database" in 32
bytes would be awfully restrictive about your user and database names.
regards, tom lane
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > + /* We append database name if db_user_namespace true. */ > > + #define SM_DATABASE_USER (SM_DATABASE+SM_USER) > > Is this calculation correct? I'd think you'd need at least one more > character to allow for the "@". And I'm not sure about whether trailing > nulls are or need to be counted. There seem to be some places in your > patch where things are dimensioned SM_DATABASE_USER and some where it's > SM_DATABASE_USER+1; why the inconsistency, and which is right? Yes, there was some inconsistency. The new patch fixes that up; attached. > Other than getting the array sizes right, it does look like a nice > patch; very small, which is what I'd hoped for. The notion of having to > say "postgres@" still seems kinda ugly, but given the simplicity of the > patch I'm willing to live with that. Glad we have something now everyone likes, or at least can live with. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 Index: doc/src/sgml/runtime.sgml =================================================================== RCS file: /cvsroot/pgsql-server/doc/src/sgml/runtime.sgml,v retrieving revision 1.125 diff -c -r1.125 runtime.sgml *** doc/src/sgml/runtime.sgml 15 Aug 2002 14:26:15 -0000 1.125 --- doc/src/sgml/runtime.sgml 15 Aug 2002 16:34:12 -0000 *************** *** 1191,1196 **** --- 1191,1211 ---- </varlistentry> <varlistentry> + <term><varname>DB_USER_NAMESPACE</varname> (<type>boolean</type>)</term> + <listitem> + <para> + Appends <literal>@</> and the database name to the user name when + connecting to the database. This allows per-database users. + User names ending with <literal>@</> are considered global and may + connect to any database. It is recommended you create at least one + global user, e.g. <literal>postgres@</>, before enabling this feature. + Also, when creating user names containing <literal>@</>, you will need + to quote the user name. + </para> + </listitem> + </varlistentry> + + <varlistentry> <indexterm> <primary>deadlock</primary> <secondary>timeout</secondary> Index: src/backend/libpq/auth.c =================================================================== RCS file: /cvsroot/pgsql-server/src/backend/libpq/auth.c,v retrieving revision 1.82 diff -c -r1.82 auth.c *** src/backend/libpq/auth.c 20 Jun 2002 20:29:28 -0000 1.82 --- src/backend/libpq/auth.c 15 Aug 2002 16:34:13 -0000 *************** *** 117,123 **** version, PG_KRB4_VERSION); return STATUS_ERROR; } ! if (strncmp(port->user, auth_data.pname, SM_USER) != 0) { elog(LOG, "pg_krb4_recvauth: name \"%s\" != \"%s\"", port->user, auth_data.pname); --- 117,123 ---- version, PG_KRB4_VERSION); return STATUS_ERROR; } ! if (strncmp(port->user, auth_data.pname, SM_DATABASE_USER) != 0) { elog(LOG, "pg_krb4_recvauth: name \"%s\" != \"%s\"", port->user, auth_data.pname); *************** *** 290,296 **** } kusername = pg_an_to_ln(kusername); ! if (strncmp(port->user, kusername, SM_USER)) { elog(LOG, "pg_krb5_recvauth: user name \"%s\" != krb5 name \"%s\"", port->user, kusername); --- 290,296 ---- } kusername = pg_an_to_ln(kusername); ! if (strncmp(port->user, kusername, SM_DATABASE_USER)) { elog(LOG, "pg_krb5_recvauth: user name \"%s\" != krb5 name \"%s\"", port->user, kusername); Index: src/backend/postmaster/postmaster.c =================================================================== RCS file: /cvsroot/pgsql-server/src/backend/postmaster/postmaster.c,v retrieving revision 1.283 diff -c -r1.283 postmaster.c *** src/backend/postmaster/postmaster.c 10 Aug 2002 20:29:18 -0000 1.283 --- src/backend/postmaster/postmaster.c 15 Aug 2002 16:34:15 -0000 *************** *** 116,122 **** sigset_t UnBlockSig, BlockSig, AuthBlockSig; - #else int UnBlockSig, BlockSig, --- 116,121 ---- *************** *** 191,196 **** --- 190,197 ---- bool HostnameLookup; /* for ps display */ bool ShowPortNumber; bool Log_connections = false; + bool Db_user_namespace = false; + /* Startup/shutdown state */ static pid_t StartupPID = 0, *************** *** 1161,1166 **** --- 1162,1177 ---- if (port->user[0] == '\0') elog(FATAL, "no PostgreSQL user name specified in startup packet"); + /* Append database name for per-db user namespace, exclude global users. */ + if (Db_user_namespace && strlen(port->user) > 0 && + port->user[strlen(port->user)-1] != '@') + { + char hold_user[SM_DATABASE_USER+1]; + snprintf(hold_user, SM_DATABASE_USER+1, "%s@%s", port->user, + port->database); + strcpy(port->user, hold_user); + } + /* * If we're going to reject the connection due to database state, say * so now instead of wasting cycles on an authentication exchange. *************** *** 2587,2597 **** if (FindExec(fullprogname, argv[0], "postmaster") < 0) return false; ! filename = palloc(strlen(DataDir) + 20); sprintf(filename, "%s/postmaster.opts", DataDir); ! fp = fopen(filename, "w"); ! if (fp == NULL) { postmaster_error("cannot create file %s: %s", filename, strerror(errno)); --- 2598,2607 ---- if (FindExec(fullprogname, argv[0], "postmaster") < 0) return false; ! filename = palloc(strlen(DataDir) + 17); sprintf(filename, "%s/postmaster.opts", DataDir); ! if ((fp = fopen(filename, "w")) == NULL) { postmaster_error("cannot create file %s: %s", filename, strerror(errno)); Index: src/backend/utils/misc/guc.c =================================================================== RCS file: /cvsroot/pgsql-server/src/backend/utils/misc/guc.c,v retrieving revision 1.82 diff -c -r1.82 guc.c *** src/backend/utils/misc/guc.c 15 Aug 2002 02:51:26 -0000 1.82 --- src/backend/utils/misc/guc.c 15 Aug 2002 16:34:17 -0000 *************** *** 483,488 **** --- 483,492 ---- { "transform_null_equals", PGC_USERSET }, &Transform_null_equals, false, NULL, NULL }, + { + { "db_user_namespace", PGC_SIGHUP }, &Db_user_namespace, + false, NULL, NULL + }, { { NULL, 0 }, NULL, false, NULL, NULL Index: src/backend/utils/misc/postgresql.conf.sample =================================================================== RCS file: /cvsroot/pgsql-server/src/backend/utils/misc/postgresql.conf.sample,v retrieving revision 1.44 diff -c -r1.44 postgresql.conf.sample *** src/backend/utils/misc/postgresql.conf.sample 12 Aug 2002 00:36:12 -0000 1.44 --- src/backend/utils/misc/postgresql.conf.sample 15 Aug 2002 16:34:17 -0000 *************** *** 113,119 **** # # Message display # - #server_min_messages = notice # Values, in order of decreasing detail: # debug5, debug4, debug3, debug2, debug1, # info, notice, warning, error, log, fatal, --- 113,118 ---- *************** *** 201,203 **** --- 200,203 ---- #sql_inheritance = true #transform_null_equals = false #statement_timeout = 0 # 0 is disabled + #db_user_namespace = false Index: src/include/libpq/libpq-be.h =================================================================== RCS file: /cvsroot/pgsql-server/src/include/libpq/libpq-be.h,v retrieving revision 1.32 diff -c -r1.32 libpq-be.h *** src/include/libpq/libpq-be.h 20 Jun 2002 20:29:49 -0000 1.32 --- src/include/libpq/libpq-be.h 15 Aug 2002 16:34:18 -0000 *************** *** 59,65 **** ProtocolVersion proto; char database[SM_DATABASE + 1]; ! char user[SM_USER + 1]; char options[SM_OPTIONS + 1]; char tty[SM_TTY + 1]; char auth_arg[MAX_AUTH_ARG]; --- 59,65 ---- ProtocolVersion proto; char database[SM_DATABASE + 1]; ! char user[SM_DATABASE_USER + 1]; char options[SM_OPTIONS + 1]; char tty[SM_TTY + 1]; char auth_arg[MAX_AUTH_ARG]; Index: src/include/libpq/pqcomm.h =================================================================== RCS file: /cvsroot/pgsql-server/src/include/libpq/pqcomm.h,v retrieving revision 1.65 diff -c -r1.65 pqcomm.h *** src/include/libpq/pqcomm.h 12 Aug 2002 14:35:26 -0000 1.65 --- src/include/libpq/pqcomm.h 15 Aug 2002 16:34:18 -0000 *************** *** 114,119 **** --- 114,121 ---- #define SM_DATABASE 64 /* SM_USER should be the same size as the others. bjm 2002-06-02 */ #define SM_USER 32 + /* We append database name if db_user_namespace true. */ + #define SM_DATABASE_USER (SM_DATABASE+SM_USER+1) /* +1 for @ */ #define SM_OPTIONS 64 #define SM_UNUSED 64 #define SM_TTY 64 *************** *** 124,135 **** --- 126,139 ---- { ProtocolVersion protoVersion; /* Protocol version */ char database[SM_DATABASE]; /* Database name */ + /* Db_user_namespace appends dbname */ char user[SM_USER]; /* User name */ char options[SM_OPTIONS]; /* Optional additional args */ char unused[SM_UNUSED]; /* Unused */ char tty[SM_TTY]; /* Tty for debug output */ } StartupPacket; + extern bool Db_user_namespace; /* These are the authentication requests sent by the backend. */
> But how many people would even use it? I can't see adding the bloat > unnecessarily and risking it accidently being turned on. Am I wrong > and really alot of people actually want/need this? At an absolute minimum there are two. Myself and Marc. That said, this is a semi-required step to offerring Postgresql as a service to clients. The refined permissions where a much more important step. So, take the number of people actively watching -hackers and use that as a percentage.
On Thu, 15 Aug 2002, Tom Lane wrote: > Vince Vielhaber <vev@michvhf.com> writes: > > But it doesn't need to affect anyone, even if it's enabled. Isn't > > the lack of an @ just as good as an @ at the end of the username? > > No, because there isn't any @ in the incoming connection request in the > normal-user case: just a user name and a database name, which *we* have > to assemble into user@database. > > We can't really expect the users to do this for us (give user@database > as their full user name). There are a number of reasons why I don't > wanna do that, but the real showstopper is that the username field of > the connection request packet is only 32 bytes wide, and we cannot > enlarge it without a protocol breakage. Fitting "user@database" in 32 > bytes would be awfully restrictive about your user and database names. Ok, I misunderstood. I thought it was the user going to have to type that in based on some of yesterday's comments. Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net 56K Nationwide Dialup from $16.00/mo atPop4 Networking http://www.camping-usa.com http://www.cloudninegifts.com http://www.meanstreamradio.com http://www.unknown-artists.com ==========================================================================
Bruce Momjian writes: > OK, I have another idea. What if we make global users end with an @, so > dave@ is a global user. We can easily check for that in the postmaster > and not append the dbname. I know it makes @ a special character, but > considering the problem of namespace collision, it seems better than > what we have now. We could add the install user too if we wish, or just > tell them to make sure they add a user@ before turning on the feature. I don't like where this is going. The original plan was to create a feature that was simple and transparent. Now we have a feature that might be simple to implement, but is neither simple to understand nor transparent. Instead it uglifies the common interfaces. I don't see what the problem is of dumping out the entire content of pg_shadow into a flat file. First you look for a non-@ user, then you look for an @ user that matches the database. The interface should drive the implementation, not the other way around. -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut <peter_e@gmx.net> writes:
> I don't see what the problem is of dumping out the entire content of
> pg_shadow into a flat file. First you look for a non-@ user, then you
> look for an @ user that matches the database.
While I'd prefer that approach myself, the way Bruce is proposing does
have a definite advantage: there is no problem with confusion between
global users and database-local users of the same username. "foo@" is
global, "foo" is not.
My own feeling is that the confusion argument is a weak one, and that
not having to use "@" to log in as a global user would be worth having
to avoid duplicating global and local names. But I'm not sufficiently
excited about it to volunteer to do the work ;-)
regards, tom lane
On Thu, 15 Aug 2002, Tom Lane wrote: > Peter Eisentraut <peter_e@gmx.net> writes: > > I don't see what the problem is of dumping out the entire content of > > pg_shadow into a flat file. First you look for a non-@ user, then you > > look for an @ user that matches the database. > > While I'd prefer that approach myself, the way Bruce is proposing does > have a definite advantage: there is no problem with confusion between > global users and database-local users of the same username. "foo@" is > global, "foo" is not. > > My own feeling is that the confusion argument is a weak one, and that > not having to use "@" to log in as a global user would be worth having > to avoid duplicating global and local names. But I'm not sufficiently > excited about it to volunteer to do the work ;-) Here we go again. I thought you just said that the @ wouldn't be something a user would have to do. I understood that to be any user. It's back to ugly again. Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net 56K Nationwide Dialup from $16.00/mo atPop4 Networking http://www.camping-usa.com http://www.cloudninegifts.com http://www.meanstreamradio.com http://www.unknown-artists.com ==========================================================================
vev@michvhf.com (Vince Vielhaber) wrote > Here we go again. I thought you just said that the @ wouldn't be > something a user would have to do. I understood that to be any user. > It's back to ugly again. > > Vince. If it means anything to you, I agree that it should be a configure/compile time option and not a GUC variable -- no, actually this whole thing should just be distributed as diff in contrib and if someone wants it they could patch it by hand, thats just as asinine as the current implemenation. What about actually incorporating this into the privileges system?
Tom Lane wrote: > Peter Eisentraut <peter_e@gmx.net> writes: > > I don't see what the problem is of dumping out the entire content of > > pg_shadow into a flat file. First you look for a non-@ user, then you > > look for an @ user that matches the database. > > While I'd prefer that approach myself, the way Bruce is proposing does > have a definite advantage: there is no problem with confusion between > global users and database-local users of the same username. "foo@" is > global, "foo" is not. > > My own feeling is that the confusion argument is a weak one, and that > not having to use "@" to log in as a global user would be worth having > to avoid duplicating global and local names. But I'm not sufficiently > excited about it to volunteer to do the work ;-) If we don't suffix global users with '@', a global user named 'dave' could not attach to a database called 'db1' as himself if a user called 'dave@db1' existed. If you have a super-user, who you want to be able to connect to any database, the creation of that name in any database would block the superuser from connecting as themselves. That is the confusion I want to avoid. I have seen some negative reactions to the feature. I am willing to ask for a vote, if that is what people want. If not, I will apply the patch in the next day or two. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
> I have seen some negative reactions to the feature. I am willing to ask > for a vote, if that is what people want. If not, I will apply the patch > in the next day or two. Please apply.
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> If we don't suffix global users with '@', a global user named 'dave'
> could not attach to a database called 'db1' as himself if a user called
> 'dave@db1' existed.
No, it's the other way around (assuming you check user before user@db):
the existence of a global user would prevent similarly-named local users
from connecting. This does not strike me as too terrible, assuming that
there are not very many global users.
regards, tom lane
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > If we don't suffix global users with '@', a global user named 'dave' > > could not attach to a database called 'db1' as himself if a user called > > 'dave@db1' existed. > > No, it's the other way around (assuming you check user before user@db): > the existence of a global user would prevent similarly-named local users > from connecting. This does not strike me as too terrible, assuming that > there are not very many global users. Yes, something like that. It could go either way. I never actually coded the double checking. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
On Thu, 15 Aug 2002, Bruce Momjian wrote: > I have seen some negative reactions to the feature. I am willing to ask > for a vote, if that is what people want. If not, I will apply the patch > in the next day or two. So are you calling for a vote or just willing to ask for one? I vote for putting it in contrib and letting whoever wants it apply it and use it. The more we discuss it the worse it looks. Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net 56K Nationwide Dialup from $16.00/mo atPop4 Networking http://www.camping-usa.com http://www.cloudninegifts.com http://www.meanstreamradio.com http://www.unknown-artists.com ==========================================================================
Vince Vielhaber <vev@michvhf.com> writes:
> So are you calling for a vote or just willing to ask for one? I vote for
> putting it in contrib and letting whoever wants it apply it and use it.
The trouble with putting it in contrib is that that makes it effectively
unavailable to anyone who installs from RPMs, or otherwise doesn't build
from source for themselves. Putting a patch diff in contrib is a bad
idea anyway since the patch will suffer bit-rot in no time, as the
referenced files change.
Since the patch is small and doesn't change behavior or performance if
you don't enable the feature, I don't think there's a good reason to
push it off to contrib just because it's ugly.
> The more we discuss it the worse it looks.
I still like the other way better --- but I'm still not prepared to do
the legwork to make it happen, so I have to defer to whatever Bruce is
willing to implement.
regards, tom lane
On Fri, 16 Aug 2002, Tom Lane wrote: > Vince Vielhaber <vev@michvhf.com> writes: > > So are you calling for a vote or just willing to ask for one? I vote for > > putting it in contrib and letting whoever wants it apply it and use it. > > The trouble with putting it in contrib is that that makes it effectively > unavailable to anyone who installs from RPMs, or otherwise doesn't build > from source for themselves. Putting a patch diff in contrib is a bad > idea anyway since the patch will suffer bit-rot in no time, as the > referenced files change. RPMs aren't a good enough reason to put it in. All features aren't installed in an RPM, why would this need to? Besides, anything that is runtime configurable can end up getting its default changed on a whim. Then again as long as 7.2.1 is stable enough for me there's no reason to upgrade 'cuze I damn sure ain't going back and changing all sorts of programs and scripts that have global users. Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net 56K Nationwide Dialup from $16.00/mo atPop4 Networking http://www.camping-usa.com http://www.cloudninegifts.com http://www.meanstreamradio.com http://www.unknown-artists.com ==========================================================================
Vince Vielhaber writes:> [ 'user@' patch ]> whim. Then again as long as 7.2.1 is stable enough for me there's> no reasonto upgrade 'cuze I damn sure ain't going back and changing> all sorts of programs and scripts that have global users. Having read bits and pieces of this thread, can those in favour confirm that this would be an effect of this patch? If so I fail to see the usefulness of this and indeed it would be very harmful to existing installations! All use of PostgreSQL utilities in scripts for our product always do a '-U sprint' to use a global user, this aids our internal development and makes installation notes for clients easier... Also what effect would adding significance to '@' in the context of usernames have, if any, on the current use of it as a database/host separator (in ECPG, certainly would be useful in the utilities too)? Thanks, Lee.
Lee Kindness <lkindness@csl.co.uk> writes:
> Vince Vielhaber writes:
>>> [ 'user@' patch ]
>>> whim. Then again as long as 7.2.1 is stable enough for me there's
>>> no reason to upgrade 'cuze I damn sure ain't going back and changing
>>> all sorts of programs and scripts that have global users.
> Having read bits and pieces of this thread, can those in favour
> confirm that this would be an effect of this patch?
I think Vince is talking through his hat. The proposed flag wouldn't
ever be enabled by default. If someone did turn it on in their
installation "on a whim", they'd soon turn it off again if they didn't
like the effects. I do not see much difference between the above
argument and arguing "we shouldn't have i18n support, because if I
turned it on on a whim I wouldn't be able to read my error messages".
Once again: *no one* has at any time suggested that any form of this
patch should affect the default behavior in the slightest.
> Also what effect would adding significance to '@' in the context of
> usernames have, if any, on the current use of it as a database/host
> separator (in ECPG, certainly would be useful in the utilities too)?
Well, I don't see any difficulty there, but if you are aware of a
context where it'd be a problem, point it out!
regards, tom lane
On Fri, Aug 16, 2002 at 10:21:12AM -0400, Vince Vielhaber wrote: > RPMs aren't a good enough reason to put it in. All features aren't > installed in an RPM, why would this need to? Besides, anything that > is runtime configurable can end up getting its default changed on a > whim. Then again as long as 7.2.1 is stable enough for me there's > no reason to upgrade 'cuze I damn sure ain't going back and changing > all sorts of programs and scripts that have global users. So, Vince, do you have problems with the various GUC based optimizer hooks getting set to other than the default? I'd think you'd notice if suddenly indexscans all went away, or any of these: #enable_seqscan = true #enable_indexscan = true #enable_tidscan = true #enable_sort = true #enable_nestloop = true #enable_mergejoin = true #enable_hashjoin = true My point is that your resistance to a GUC controlled runtime configurable on the basis of 'it might get changed accidently' makes little sense to me, given all the other runtime config settings that never do get changed. What makes you think this one will be more susceptible to accidental flipping? I'm not sure who's 'whim' it is that your afraid of: perhaps you have a paticularly sadistic DBA to deal with? ;-) And of course, this being free software and all, noone is forcing an upgrade on you. Ross
On Fri, 2002-08-16 at 09:51, Ross J. Reedstrom wrote: > On Fri, Aug 16, 2002 at 10:21:12AM -0400, Vince Vielhaber wrote: > > > RPMs aren't a good enough reason to put it in. All features aren't > > installed in an RPM, why would this need to? Besides, anything that > > is runtime configurable can end up getting its default changed on a > > whim. Then again as long as 7.2.1 is stable enough for me there's > > no reason to upgrade 'cuze I damn sure ain't going back and changing > > all sorts of programs and scripts that have global users. > > So, Vince, do you have problems with the various GUC based optimizer > hooks getting set to other than the default? I'd think you'd notice > if suddenly indexscans all went away, or any of these: > > #enable_seqscan = true > #enable_indexscan = true > #enable_tidscan = true > #enable_sort = true > #enable_nestloop = true > #enable_mergejoin = true > #enable_hashjoin = true > > My point is that your resistance to a GUC controlled runtime configurable > on the basis of 'it might get changed accidently' makes little sense to > me, given all the other runtime config settings that never do get changed. > What makes you think this one will be more susceptible to accidental > flipping? > > I'm not sure who's 'whim' it is that your afraid of: perhaps you have a > paticularly sadistic DBA to deal with? ;-) And of course, this being > free software and all, noone is forcing an upgrade on you. AND, I thought the general consensus was **AWAY** from configure time directives and to GUC variables whenever **POSSIBLE**. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Vince Vielhaber wrote: > On Thu, 15 Aug 2002, Bruce Momjian wrote: > > > I have seen some negative reactions to the feature. I am willing to ask > > for a vote, if that is what people want. If not, I will apply the patch > > in the next day or two. > > So are you calling for a vote or just willing to ask for one? I vote for > putting it in contrib and letting whoever wants it apply it and use it. > The more we discuss it the worse it looks. I can do a vote. However, seeing many positive comments about the patch, and 1-2 negative ones (with no suggestion on how to improve it), I don't think the negative votes will win. I usually do a vote when the email comments are coming in kind of close. Specifically, in the thread, I have Vince and Peter as negative, and >7 positive, I think. Look at the contraints I am under to implement what is effectively username schemas: small patch, no bloat, because it isn't a core featuremultiple global usersno namespace collisions between global/non-globaluserszero performance impact32-byte user string coming from the client Specifically, what is ugly about it? Is it that global users have an @ at the end of their names? How do we prevent namespace collisions _without_ doing this? I am all ears. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Specifically, what is ugly about it? Is it that global users have an @
> at the end of their names? How do we prevent namespace collisions
> _without_ doing this? I am all ears.
The folks who are unhappy about this design basically think that the
namespace collisions issue should not be considered a vital requirement;
whereupon you don't have to have the '@' because a search in the
pg_shadow flat file would work well enough.
It comes down to a judgment call about which is uglier, putting '@' on
global usernames or having to avoid namespace collisions.
At this point I think we've wasted more than enough time on the
argument; I haven't seen any new ideas recently, nor any change in
anyone's position. Since no one seems to want to do the work to make a
better implementation, I vote we accept the patch we have and move on.
regards, tom lane
On Fri, 16 Aug 2002, Tom Lane wrote: > Lee Kindness <lkindness@csl.co.uk> writes: > > Vince Vielhaber writes: > >>> [ 'user@' patch ] > >>> whim. Then again as long as 7.2.1 is stable enough for me there's > >>> no reason to upgrade 'cuze I damn sure ain't going back and changing > >>> all sorts of programs and scripts that have global users. > > > Having read bits and pieces of this thread, can those in favour > > confirm that this would be an effect of this patch? > > I think Vince is talking through his hat. The proposed flag wouldn't > ever be enabled by default. If someone did turn it on in their > installation "on a whim", they'd soon turn it off again if they didn't > like the effects. I do not see much difference between the above > argument and arguing "we shouldn't have i18n support, because if I > turned it on on a whim I wouldn't be able to read my error messages". > > Once again: *no one* has at any time suggested that any form of this > patch should affect the default behavior in the slightest. Not yet they haven't. What happens when it's decided that this *feature* is a good thing and should be the default? Maybe not now, but can you guarantee that that won't happen in say 7.4? Or maybe 8.0? I can hear it now, "Well we're giving you an entire version to change your scripts". There's not even a concensus that this is the right way to do it, you even said you'd prefer it was implemented in another way but don't have the time to do it. Since when does this group rush to stuff features in without agreement even on HOW to implement it? Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net 56K Nationwide Dialup from $16.00/mo atPop4 Networking http://www.camping-usa.com http://www.cloudninegifts.com http://www.meanstreamradio.com http://www.unknown-artists.com ==========================================================================
Vince Vielhaber wrote: > > Once again: *no one* has at any time suggested that any form of this > > patch should affect the default behavior in the slightest. > > Not yet they haven't. What happens when it's decided that this > *feature* is a good thing and should be the default? Maybe not > now, but can you guarantee that that won't happen in say 7.4? Or > maybe 8.0? I can hear it now, "Well we're giving you an entire > version to change your scripts". I can't argue hypothetical with you, but if we decided to make this a default behavior, we would probably push the functionality down into CREATE USER, create a new column in pg_shadow, lengthen the username passed from the client, and do it that way. However, because it is not on by default _and_ we don't want to add visibility to a functionality that is off by default, we are doing it this way. Remember, non-local users already have an @ in their username. I am just adding @ to the global users too. This functionality actually allows you to keep your old users in pg_shadow and once you turn on the feature, those users become unusable. When you turn the feature off, they are back again. I know the trailing @ is ugly, but it prevents surpises when connecting to the database. > There's not even a consensus that this is the right way to do it, > you even said you'd prefer it was implemented in another way but > don't have the time to do it. Since when does this group rush to > stuff features in without agreement even on HOW to implement it? This is an argument I don't want to bow to. How many features have we left undone, for release after release, because we couldn't find a perfect way to do it, so we did nothing, and users went elsewhere for their database needs? We have had enough discussion to know that there isn't a perfect solution in this case, so we are going to implement the best we can, and if we have to revisit it in 8.0, so be it. I am sure you will still be around to help craft that solution. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
On Fri, 16 Aug 2002, Ross J. Reedstrom wrote: > On Fri, Aug 16, 2002 at 10:21:12AM -0400, Vince Vielhaber wrote: > > > RPMs aren't a good enough reason to put it in. All features aren't > > installed in an RPM, why would this need to? Besides, anything that > > is runtime configurable can end up getting its default changed on a > > whim. Then again as long as 7.2.1 is stable enough for me there's > > no reason to upgrade 'cuze I damn sure ain't going back and changing > > all sorts of programs and scripts that have global users. > > So, Vince, do you have problems with the various GUC based optimizer > hooks getting set to other than the default? I'd think you'd notice > if suddenly indexscans all went away, or any of these: > > #enable_seqscan = true > #enable_indexscan = true > #enable_tidscan = true > #enable_sort = true > #enable_nestloop = true > #enable_mergejoin = true > #enable_hashjoin = true > > My point is that your resistance to a GUC controlled runtime configurable > on the basis of 'it might get changed accidently' makes little sense to > me, given all the other runtime config settings that never do get changed. > What makes you think this one will be more susceptible to accidental > flipping? My point has nothing to do with resistance to GUC configurables. Someone WILL decide that having it as a default is a *Good Thing* because it's there and is useful to them and in its current implementation there's not even a concensus that it's the right way to do it. It's being rushed into this version unnecessarily. Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net 56K Nationwide Dialup from $16.00/mo atPop4 Networking http://www.camping-usa.com http://www.cloudninegifts.com http://www.meanstreamradio.com http://www.unknown-artists.com ==========================================================================
Vince Vielhaber <vev@michvhf.com> writes:
> My point has nothing to do with resistance to GUC configurables. Someone
> WILL decide that having it as a default is a *Good Thing* because it's
> there and is useful to them
Which someone would this be? There's no chance that such a proposal
would pass a pghackers vote, and certainly no chance that someone
could commit such a change into CVS without everyone noticing.
> and in its current implementation there's not
> even a concensus that it's the right way to do it. It's being rushed into
> this version unnecessarily.
It's being rushed into this version because we need a stopgap solution.
I don't see it as anything but a stopgap. The fact that it's a very
small patch is good, because it can be replaced with minimal effort once
someone has the time to design and implement a better mechanism for
multi-database user management. AFAICT a proper solution will involve
considerable work, and I don't see it happening in time for 7.3.
Also, ugly as this may be, it's still better than the old solution for
people who are trying to support multiple similarly-named users in
different databases. The old hack required external password files
which mean manual management, admin involvement in any password change,
etc. With this approach users can set their password normally even if
they're being restricted to one database. So realistically I think this
does not affect people who aren't using it, and for people who do want
to use it it's a step forward, even if not as far forward as we'd like.
regards, tom lane
BTW, I just thought of a small improvement to your patch that eliminates
some of the ugliness. Suppose that when we recognize an attempt to
connect as a global user (ie, feature flag is on and last character of
username is '@'), we strip off the '@' before proceeding. Then we would
have:global users appear in pg_shadow as foolocal users appear in pg_shadow as foo@db
and what this would mean is that you can flip between feature-enabled
and feature-disabled states without breaking your global logins. So you
don't need the extra step of creating a "postgres@" before turning on
the feature. (Which was pretty ugly anyway, since even though postgres@
could be made a superuser, he wouldn't be the same user as postgres ---
this affects table ownership, for example, and would be a serious issue
if you wanted any non-superuser global users.)
I suppose some might argue that having to say postgres@ to log in,
when your username is really just postgres as far as you can see in the
database, is a tad confusing. But the whole thing is an acknowledged
wart anyway, and I think getting rid of the two problems mentioned above
is worth it.
Also, if we do this then it's important to strip a trailing '@' only
if it's the *only* one in the given username. Else a local user
'foo@db1' could cheat to log into db2 by saying username = 'foo@db1@'
with requested database db2. But I can't see any other security hole.
regards, tom lane
Tom Lane wrote: > BTW, I just thought of a small improvement to your patch that eliminates > some of the ugliness. Suppose that when we recognize an attempt to > connect as a global user (ie, feature flag is on and last character of > username is '@'), we strip off the '@' before proceeding. Then we would > have: > global users appear in pg_shadow as foo > local users appear in pg_shadow as foo@db > and what this would mean is that you can flip between feature-enabled > and feature-disabled states without breaking your global logins. So you > don't need the extra step of creating a "postgres@" before turning on > the feature. (Which was pretty ugly anyway, since even though postgres@ > could be made a superuser, he wouldn't be the same user as postgres --- > this affects table ownership, for example, and would be a serious issue > if you wanted any non-superuser global users.) > > I suppose some might argue that having to say postgres@ to log in, > when your username is really just postgres as far as you can see in the > database, is a tad confusing. But the whole thing is an acknowledged > wart anyway, and I think getting rid of the two problems mentioned above > is worth it. Sure. If I can get one more 'yes' I will submit a new patch with the change. It does prevent the namespace collision without mucking up pg_shadow. We only need to tell people that global users need to supply their username to the client as user@. Is that cleaner? > Also, if we do this then it's important to strip a trailing '@' only > if it's the *only* one in the given username. Else a local user > 'foo@db1' could cheat to log into db2 by saying username = 'foo@db1@' > with requested database db2. But I can't see any other security hole. Ewe, I didn't think of that. Good point. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
On Fri, 2002-08-16 at 20:03, Bruce Momjian wrote: > Sure. If I can get one more 'yes' I will submit a new patch with the > change. It does prevent the namespace collision without mucking up > pg_shadow. We only need to tell people that global users need to supply > their username to the client as user@. Is that cleaner? I will vote yes for this change. I think the flexibility this new system offers will make it much easier for people to offer PostgreSQL hosting facilities, of which I would like to see many more. -- Oliver Elphick Oliver.Elphick@lfix.co.uk Isle of Wight, UK http://www.lfix.co.uk/oliver GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C ======================================== "And whatsoever ye shall ask in my name, that will I do, that the Fathermay be glorified in the Son." John 14:13
pgman@candle.pha.pa.us (Bruce Momjian) wrote > > I know the trailing @ is ugly, but it prevents surpises when connecting > to the database. > if you would make the magic character a variable then perhaps you could prevent the ugly... if/when you turn off the feature, you could set the PGSQL_STUPID_MAGIC_CHARACTER to '', then you would be appending an empty string instead of a @, when you want to turn it back on, set the variable back to '@'... and if you change the character, well dont..
ngpg@grymmjack.com wrote: > pgman@candle.pha.pa.us (Bruce Momjian) wrote > > > > I know the trailing @ is ugly, but it prevents surpises when connecting > > to the database. > > > > if you would make the magic character a variable then perhaps you could > prevent the ugly... if/when you turn off the feature, you could set the > PGSQL_STUPID_MAGIC_CHARACTER to '', then you would be appending an empty > string instead of a @, when you want to turn it back on, set the variable > back to '@'... and if you change the character, well dont.. It already does that. When it is off, it works just like it does in 7.2. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
OK, here is the patch with the suggested changes. I am sending the patch to hackers because there has been so much interest in this. --------------------------------------------------------------------------- Tom Lane wrote: > BTW, I just thought of a small improvement to your patch that eliminates > some of the ugliness. Suppose that when we recognize an attempt to > connect as a global user (ie, feature flag is on and last character of > username is '@'), we strip off the '@' before proceeding. Then we would > have: > global users appear in pg_shadow as foo > local users appear in pg_shadow as foo@db > and what this would mean is that you can flip between feature-enabled > and feature-disabled states without breaking your global logins. So you > don't need the extra step of creating a "postgres@" before turning on > the feature. (Which was pretty ugly anyway, since even though postgres@ > could be made a superuser, he wouldn't be the same user as postgres --- > this affects table ownership, for example, and would be a serious issue > if you wanted any non-superuser global users.) > > I suppose some might argue that having to say postgres@ to log in, > when your username is really just postgres as far as you can see in the > database, is a tad confusing. But the whole thing is an acknowledged > wart anyway, and I think getting rid of the two problems mentioned above > is worth it. > > Also, if we do this then it's important to strip a trailing '@' only > if it's the *only* one in the given username. Else a local user > 'foo@db1' could cheat to log into db2 by saying username = 'foo@db1@' > with requested database db2. But I can't see any other security hole. > > regards, tom lane > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 Index: doc/src/sgml/runtime.sgml =================================================================== RCS file: /cvsroot/pgsql-server/doc/src/sgml/runtime.sgml,v retrieving revision 1.125 diff -c -r1.125 runtime.sgml *** doc/src/sgml/runtime.sgml 15 Aug 2002 14:26:15 -0000 1.125 --- doc/src/sgml/runtime.sgml 17 Aug 2002 04:14:34 -0000 *************** *** 1191,1196 **** --- 1191,1216 ---- </varlistentry> <varlistentry> + <term><varname>DB_USER_NAMESPACE</varname> (<type>boolean</type>)</term> + <listitem> + <para> + This allows per-database user names. You can create users as <literal> + username@dbname</>. When <literal>username</> is passed by the client, + <literal>@</> and the database name is appended to the user name and + that database-specific user name is looked up by the server. + When creating user names containing <literal>@</>, you will need + to quote the user name. + </para> + <para> + With this option enabled, you can still create ordinary global + users. Simply append <literal>@</> when specifying the user name + in the client. The <literal>@</> will be stripped off and looked up + by the server. + </para> + </listitem> + </varlistentry> + + <varlistentry> <indexterm> <primary>deadlock</primary> <secondary>timeout</secondary> Index: src/backend/libpq/auth.c =================================================================== RCS file: /cvsroot/pgsql-server/src/backend/libpq/auth.c,v retrieving revision 1.82 diff -c -r1.82 auth.c *** src/backend/libpq/auth.c 20 Jun 2002 20:29:28 -0000 1.82 --- src/backend/libpq/auth.c 17 Aug 2002 04:14:35 -0000 *************** *** 117,123 **** version, PG_KRB4_VERSION); return STATUS_ERROR; } ! if (strncmp(port->user, auth_data.pname, SM_USER) != 0) { elog(LOG, "pg_krb4_recvauth: name \"%s\" != \"%s\"", port->user, auth_data.pname); --- 117,123 ---- version, PG_KRB4_VERSION); return STATUS_ERROR; } ! if (strncmp(port->user, auth_data.pname, SM_DATABASE_USER) != 0) { elog(LOG, "pg_krb4_recvauth: name \"%s\" != \"%s\"", port->user, auth_data.pname); *************** *** 290,296 **** } kusername = pg_an_to_ln(kusername); ! if (strncmp(port->user, kusername, SM_USER)) { elog(LOG, "pg_krb5_recvauth: user name \"%s\" != krb5 name \"%s\"", port->user, kusername); --- 290,296 ---- } kusername = pg_an_to_ln(kusername); ! if (strncmp(port->user, kusername, SM_DATABASE_USER)) { elog(LOG, "pg_krb5_recvauth: user name \"%s\" != krb5 name \"%s\"", port->user, kusername); Index: src/backend/postmaster/postmaster.c =================================================================== RCS file: /cvsroot/pgsql-server/src/backend/postmaster/postmaster.c,v retrieving revision 1.283 diff -c -r1.283 postmaster.c *** src/backend/postmaster/postmaster.c 10 Aug 2002 20:29:18 -0000 1.283 --- src/backend/postmaster/postmaster.c 17 Aug 2002 04:14:40 -0000 *************** *** 116,122 **** sigset_t UnBlockSig, BlockSig, AuthBlockSig; - #else int UnBlockSig, BlockSig, --- 116,121 ---- *************** *** 191,196 **** --- 190,197 ---- bool HostnameLookup; /* for ps display */ bool ShowPortNumber; bool Log_connections = false; + bool Db_user_namespace = false; + /* Startup/shutdown state */ static pid_t StartupPID = 0, *************** *** 1161,1166 **** --- 1162,1182 ---- if (port->user[0] == '\0') elog(FATAL, "no PostgreSQL user name specified in startup packet"); + if (Db_user_namespace) + { + /* If user@, it is a global user, remove '@' */ + if (strchr(port->user, '@') == port->user + strlen(port->user)-1) + *strchr(port->user, '@') = '\0'; + else + { + /* Append '@' and dbname */ + char hold_user[SM_DATABASE_USER+1]; + snprintf(hold_user, SM_DATABASE_USER+1, "%s@%s", port->user, + port->database); + strcpy(port->user, hold_user); + } + } + /* * If we're going to reject the connection due to database state, say * so now instead of wasting cycles on an authentication exchange. *************** *** 2587,2597 **** if (FindExec(fullprogname, argv[0], "postmaster") < 0) return false; ! filename = palloc(strlen(DataDir) + 20); sprintf(filename, "%s/postmaster.opts", DataDir); ! fp = fopen(filename, "w"); ! if (fp == NULL) { postmaster_error("cannot create file %s: %s", filename, strerror(errno)); --- 2603,2612 ---- if (FindExec(fullprogname, argv[0], "postmaster") < 0) return false; ! filename = palloc(strlen(DataDir) + 17); sprintf(filename, "%s/postmaster.opts", DataDir); ! if ((fp = fopen(filename, "w")) == NULL) { postmaster_error("cannot create file %s: %s", filename, strerror(errno)); Index: src/backend/utils/misc/guc.c =================================================================== RCS file: /cvsroot/pgsql-server/src/backend/utils/misc/guc.c,v retrieving revision 1.82 diff -c -r1.82 guc.c *** src/backend/utils/misc/guc.c 15 Aug 2002 02:51:26 -0000 1.82 --- src/backend/utils/misc/guc.c 17 Aug 2002 04:14:49 -0000 *************** *** 483,488 **** --- 483,492 ---- { "transform_null_equals", PGC_USERSET }, &Transform_null_equals, false, NULL, NULL }, + { + { "db_user_namespace", PGC_SIGHUP }, &Db_user_namespace, + false, NULL, NULL + }, { { NULL, 0 }, NULL, false, NULL, NULL Index: src/backend/utils/misc/postgresql.conf.sample =================================================================== RCS file: /cvsroot/pgsql-server/src/backend/utils/misc/postgresql.conf.sample,v retrieving revision 1.44 diff -c -r1.44 postgresql.conf.sample *** src/backend/utils/misc/postgresql.conf.sample 12 Aug 2002 00:36:12 -0000 1.44 --- src/backend/utils/misc/postgresql.conf.sample 17 Aug 2002 04:14:50 -0000 *************** *** 113,119 **** # # Message display # - #server_min_messages = notice # Values, in order of decreasing detail: # debug5, debug4, debug3, debug2, debug1, # info, notice, warning, error, log, fatal, --- 113,118 ---- *************** *** 201,203 **** --- 200,203 ---- #sql_inheritance = true #transform_null_equals = false #statement_timeout = 0 # 0 is disabled + #db_user_namespace = false Index: src/include/libpq/libpq-be.h =================================================================== RCS file: /cvsroot/pgsql-server/src/include/libpq/libpq-be.h,v retrieving revision 1.32 diff -c -r1.32 libpq-be.h *** src/include/libpq/libpq-be.h 20 Jun 2002 20:29:49 -0000 1.32 --- src/include/libpq/libpq-be.h 17 Aug 2002 04:14:50 -0000 *************** *** 59,65 **** ProtocolVersion proto; char database[SM_DATABASE + 1]; ! char user[SM_USER + 1]; char options[SM_OPTIONS + 1]; char tty[SM_TTY + 1]; char auth_arg[MAX_AUTH_ARG]; --- 59,65 ---- ProtocolVersion proto; char database[SM_DATABASE + 1]; ! char user[SM_DATABASE_USER + 1]; char options[SM_OPTIONS + 1]; char tty[SM_TTY + 1]; char auth_arg[MAX_AUTH_ARG]; Index: src/include/libpq/pqcomm.h =================================================================== RCS file: /cvsroot/pgsql-server/src/include/libpq/pqcomm.h,v retrieving revision 1.65 diff -c -r1.65 pqcomm.h *** src/include/libpq/pqcomm.h 12 Aug 2002 14:35:26 -0000 1.65 --- src/include/libpq/pqcomm.h 17 Aug 2002 04:14:50 -0000 *************** *** 114,119 **** --- 114,121 ---- #define SM_DATABASE 64 /* SM_USER should be the same size as the others. bjm 2002-06-02 */ #define SM_USER 32 + /* We append database name if db_user_namespace true. */ + #define SM_DATABASE_USER (SM_DATABASE+SM_USER+1) /* +1 for @ */ #define SM_OPTIONS 64 #define SM_UNUSED 64 #define SM_TTY 64 *************** *** 124,135 **** --- 126,139 ---- { ProtocolVersion protoVersion; /* Protocol version */ char database[SM_DATABASE]; /* Database name */ + /* Db_user_namespace appends dbname */ char user[SM_USER]; /* User name */ char options[SM_OPTIONS]; /* Optional additional args */ char unused[SM_UNUSED]; /* Unused */ char tty[SM_TTY]; /* Tty for debug output */ } StartupPacket; + extern bool Db_user_namespace; /* These are the authentication requests sent by the backend. */
Sample run:$ psql -U postgres testpsql: FATAL: user "postgres@test" does not exist $ psql -U postgres@ testWelcome to psql 7.3devel, the PostgreSQL interactive terminal.Type: \copyright for distributionterms \h for help with SQL commands \? for help on internal slash commands \g or terminatewith semicolon to execute query \q to quittest=> --------------------------------------------------------------------------- Tom Lane wrote: > BTW, I just thought of a small improvement to your patch that eliminates > some of the ugliness. Suppose that when we recognize an attempt to > connect as a global user (ie, feature flag is on and last character of > username is '@'), we strip off the '@' before proceeding. Then we would > have: > global users appear in pg_shadow as foo > local users appear in pg_shadow as foo@db > and what this would mean is that you can flip between feature-enabled > and feature-disabled states without breaking your global logins. So you > don't need the extra step of creating a "postgres@" before turning on > the feature. (Which was pretty ugly anyway, since even though postgres@ > could be made a superuser, he wouldn't be the same user as postgres --- > this affects table ownership, for example, and would be a serious issue > if you wanted any non-superuser global users.) > > I suppose some might argue that having to say postgres@ to log in, > when your username is really just postgres as far as you can see in the > database, is a tad confusing. But the whole thing is an acknowledged > wart anyway, and I think getting rid of the two problems mentioned above > is worth it. > > Also, if we do this then it's important to strip a trailing '@' only > if it's the *only* one in the given username. Else a local user > 'foo@db1' could cheat to log into db2 by saying username = 'foo@db1@' > with requested database db2. But I can't see any other security hole. > > regards, tom lane > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
OK, I think we are doing this backwards. Instead of adding '@' to global users, and then removing it in the backend, why don't we have local users end with '@', that way, global users continue to connect just as they have before, and local users connect with @, so dave@db1 connects as 'dave@' and if he has other database access, he can use the same 'dave@' name. That removes some of the uglification, I think. --------------------------------------------------------------------------- Tom Lane wrote: > BTW, I just thought of a small improvement to your patch that eliminates > some of the ugliness. Suppose that when we recognize an attempt to > connect as a global user (ie, feature flag is on and last character of > username is '@'), we strip off the '@' before proceeding. Then we would > have: > global users appear in pg_shadow as foo > local users appear in pg_shadow as foo@db > and what this would mean is that you can flip between feature-enabled > and feature-disabled states without breaking your global logins. So you > don't need the extra step of creating a "postgres@" before turning on > the feature. (Which was pretty ugly anyway, since even though postgres@ > could be made a superuser, he wouldn't be the same user as postgres --- > this affects table ownership, for example, and would be a serious issue > if you wanted any non-superuser global users.) > > I suppose some might argue that having to say postgres@ to log in, > when your username is really just postgres as far as you can see in the > database, is a tad confusing. But the whole thing is an acknowledged > wart anyway, and I think getting rid of the two problems mentioned above > is worth it. > > Also, if we do this then it's important to strip a trailing '@' only > if it's the *only* one in the given username. Else a local user > 'foo@db1' could cheat to log into db2 by saying username = 'foo@db1@' > with requested database db2. But I can't see any other security hole. > > regards, tom lane > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> OK, I think we are doing this backwards. Instead of adding '@' to
> global users, and then removing it in the backend, why don't we have
> local users end with '@', that way, global users continue to connect
> just as they have before, and local users connect with @, so dave@db1
> connects as 'dave@' and if he has other database access, he can use the
> same 'dave@' name.
No, *that* would be backwards. In installations that are using this
feature, the vast majority of the users are going to be local ones.
And the global users will be the presumably-more-sophisticated admins.
Putting the onus of the '@' decoration on the local users instead of
the global ones is exactly the wrong way to go.
regards, tom lane
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > OK, I think we are doing this backwards. Instead of adding '@' to > > global users, and then removing it in the backend, why don't we have > > local users end with '@', that way, global users continue to connect > > just as they have before, and local users connect with @, so dave@db1 > > connects as 'dave@' and if he has other database access, he can use the > > same 'dave@' name. > > No, *that* would be backwards. In installations that are using this > feature, the vast majority of the users are going to be local ones. > And the global users will be the presumably-more-sophisticated admins. > Putting the onus of the '@' decoration on the local users instead of > the global ones is exactly the wrong way to go. OK, but it looks slightly less ugly. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> OK, here is the patch with the suggested changes. I am sending the
> patch to hackers because there has been so much interest in this.
One minor gripe:
> + /* If user@, it is a global user, remove '@' */
> + if (strchr(port->user, '@') == port->user + strlen(port->user)-1)
This code is correct, but it tempts someone to replace the strchr()
with a single-character check on the last character of the string.
Which would introduce the security hole we discussed before. The
code is okay, but *please* improve the comment to point out that you
are also excluding the case where there are @'s to the left of the
last character.
regards, tom lane
OK, applied, with that change. --------------------------------------------------------------------------- Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > OK, here is the patch with the suggested changes. I am sending the > > patch to hackers because there has been so much interest in this. > > One minor gripe: > > > + /* If user@, it is a global user, remove '@' */ > > + if (strchr(port->user, '@') == port->user + strlen(port->user)-1) > > This code is correct, but it tempts someone to replace the strchr() > with a single-character check on the last character of the string. > Which would introduce the security hole we discussed before. The > code is okay, but *please* improve the comment to point out that you > are also excluding the case where there are @'s to the left of the > last character. > > regards, tom lane > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Tom Lane writes: > BTW, I just thought of a small improvement to your patch that eliminates > some of the ugliness. Suppose that when we recognize an attempt to > connect as a global user (ie, feature flag is on and last character of > username is '@'), we strip off the '@' before proceeding. I'm missing how hard it is to change "last character of username is @" to "no @ in username". This would seem to be a two-line change somewhere. I'm concerned that we leave essentially no migration path, that is, the ability to turn the feature on to try it out without immediately breaking every application. -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut <peter_e@gmx.net> writes:
> I'm concerned that we leave essentially no migration path, that is, the
> ability to turn the feature on to try it out without immediately breaking
> every application.
Uh ... what? I fail to understand your objection. AFAICS the only
apps that could be "broken" are scripts that have usernames hardwired
into them ...
regards, tom lane
On Sat, 17 Aug 2002, Bruce Momjian wrote: > > OK, I think we are doing this backwards. Instead of adding '@' to > global users, and then removing it in the backend, why don't we have > local users end with '@', that way, global users continue to connect > just as they have before, and local users connect with @, so dave@db1 > connects as 'dave@' and if he has other database access, he can use the > same 'dave@' name. > > That removes some of the uglification, I think. Then why was it when I mentioned global users not having the @ you shot it down as not possible? Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net 56K Nationwide Dialup from $16.00/mo atPop4 Networking http://www.camping-usa.com http://www.cloudninegifts.com http://www.meanstreamradio.com http://www.unknown-artists.com ==========================================================================
On Sat, 17 Aug 2002, Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > OK, I think we are doing this backwards. Instead of adding '@' to > > global users, and then removing it in the backend, why don't we have > > local users end with '@', that way, global users continue to connect > > just as they have before, and local users connect with @, so dave@db1 > > connects as 'dave@' and if he has other database access, he can use the > > same 'dave@' name. > > No, *that* would be backwards. In installations that are using this > feature, the vast majority of the users are going to be local ones. > And the global users will be the presumably-more-sophisticated admins. > Putting the onus of the '@' decoration on the local users instead of > the global ones is exactly the wrong way to go. Unsophisticated users is hardly a reason. After all they do have an @ in their email address. If they're told the username is foo@ then their username is foo@. What's so difficult about that? Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net 56K Nationwide Dialup from $16.00/mo atPop4 Networking http://www.camping-usa.com http://www.cloudninegifts.com http://www.meanstreamradio.com http://www.unknown-artists.com ==========================================================================
Tom Lane writes: > Peter Eisentraut <peter_e@gmx.net> writes: > > I'm concerned that we leave essentially no migration path, that is, the > > ability to turn the feature on to try it out without immediately breaking > > every application. > > Uh ... what? I fail to understand your objection. AFAICS the only > apps that could be "broken" are scripts that have usernames hardwired > into them ... I'm completely lost between all the proposals about where the @ is going to be specified, added, or removed. What happens on the client side and what happens on the server side? All I would like to see is that I can turn on this feature and nothing changes as long as I don't add any "local users". Yes, that includes hard-wired user names on the client side. Of course there are various degrees of hard-wiring, but what if the ISP admin updates to 7.3 and wants to turn on the feature for new clients? Does he tell all his existing clients that they must update their user names? Possibly, these users got their database access with a shell account and don't specify the user name at all because it defaults to the OS user name. Does that continue to work? -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut <peter_e@gmx.net> writes:
> I'm completely lost between all the proposals about where the @ is going
> to be specified, added, or removed. What happens on the client side and
> what happens on the server side?
Well, the way things stand as of CVS tip is that (assuming you have this
feature turned on in postgresql.conf):
* If a connection request has a username with a trailing '@' (and no
embedded '@'), then the '@' is stripped and connection proceeds.
* Otherwise, '@dbname' is appended to the given username and connection
proceeds.
So a "global" user foo has to say username="foo@" in his connection
request, but he's just "foo" in pg_shadow. A "local" user foo has to
say "foo" in his connection request, and he's "foo@somedb" in pg_shadow.
> All I would like to see is that I can turn on this feature and nothing
> changes as long as I don't add any "local users". Yes, that includes
> hard-wired user names on the client side.
Well, we could have that by inverting the use of '@'; but as I commented
before, it makes more sense to me to make the global users say '@' than
to make the local users do so, because I think in an installation that
wants this feature there will be lots more local than global users.
I really don't put that much weight on the compatibility argument you
make --- not that I don't see your point, but that I don't think it
outweighs convenience of day-to-day use after one has gotten the system
set up. (Also, compatibility cuts both ways: it seems just as likely
to me that the clients with hardwired usernames are going to be ones
you want to connect as local users, as that they are going to be ones
you want to connect as global users. Maybe more likely, if you grant
the assumption that there will be more local than global users.)
It might be worth recalling the reason that we are going through this
pushup in the first place: Marc wants to be able to assign the same
username to two different users who want to access two different
databases. If he would be happy with the answer "give them two
different usernames", we'd not be having this discussion at all.
Do you think he will be happy with the answer "you can give them
the same username as long as it ends in '@'"? I think it's highly
unlikely that he'll be satisfied with that --- he wants to *not*
have constraints on the names he gives out for local users.
> Of course there are various
> degrees of hard-wiring, but what if the ISP admin updates to 7.3 and wants
> to turn on the feature for new clients? Does he tell all his existing
> clients that they must update their user names? Possibly, these users got
> their database access with a shell account and don't specify the user name
> at all because it defaults to the OS user name. Does that continue to
> work?
It works great if the ISP intends to make them all local users, which
seems more likely to me than the other case.
regards, tom lane
I'm trying to make postGIS work with pg7.3devel. But a problem is occuring that did not appear in pg7.2. When I execute: ALTER TABLE geotest ADD CHECK ( geometrytype(geopoint)='POINT' OR NULL=geopoint); I get: "ERROR: copyObject: don't know how to copy node type 506" But when I execute: ALTER TABLE geotest ADD CHECK ( geometrytype(geopoint)='POINT'); It works fine, which, due to the error message it seems that it is trying to assign rather to NULL, rather than compare (elsewhat object needs to be copied in "NULL=geopoint"?). Is this a bug, a change in NULL, or a change in user defined datatypes? Thanks; Eric
redmonde@purdue.edu writes:
> I get: "ERROR: copyObject: don't know how to copy node type 506"
This is a bug in someone's recent patch ... but you don't want to say
"NULL=geopoint" anyway, do you? Surely it should be "geopoint IS NULL".
regards, tom lane
tgl@sss.pgh.pa.us (Tom Lane) wrote > * If a connection request has a username with a trailing '@' (and no > embedded '@'), then the '@' is stripped and connection proceeds. > > * Otherwise, '@dbname' is appended to the given username and > connection proceeds. <snip> > It might be worth recalling the reason that we are going through this > pushup in the first place: Marc wants to be able to assign the same > username to two different users who want to access two different > databases. If he would be happy with the answer "give them two > different usernames", we'd not be having this discussion at all. > Do you think he will be happy with the answer "you can give them > the same username as long as it ends in '@'"? I think it's highly > unlikely that he'll be satisfied with that --- he wants to *not* > have constraints on the names he gives out for local users. What about usernames that have trailing or embedded @'s? I mean you are eseentially making the @ a magic character. I admit I havent looked at the source, but doesnt this method effectively put a constraint on the use of @? What if an isp, that could use this feature, already has usernames with @'s in them (say a customers email address, etc)? Will they need to assign all new usernames to make this thing function? What if you want to give one person (one username) access to 2 db's? Does that mean, under the current scheme, that the two accounts you create can have the same username but have different passwords? What if you want to erase the "one" account (do you have to remember to erase all n accounts you created with the same username, or all n except the ones that were never mean to be the same person but share the same username)? Normally a user has a unique name. Does anyone see a problem if/when the whole db access thing becomes part of the privileges system? If you implement the "multiple users same username", then you'll have to reassign all but one of the users to new usernames.
I'd have thought that if a matching user couldn't be found in the specified database then it would default to searching through the global users? Would be more intuitive... Lee. Bruce Momjian writes:> Sample run:> $ psql -U postgres test> psql: FATAL: user "postgres@test" does not exist> > $ psql -U postgres@ test> Welcome to psql 7.3devel, the PostgreSQL interactive terminal.
I think we need to resolve this discussion from a week ago. The current code is this: global usernames are stored just like before, e.g. postgreslocal users are stored as user@dbnamewhen connecting, global usersadd '@' to their nameswhen connecting, local users use just their user name, no @dbname Tom likes this because it is the fewer global users who have to append the '@'. Vince and Peter think that it should be local users adding '@' when connecting because: they have an @ sign in their name anywayglobal users should be able to connect unchanged I can foresee a time when we will have longer usernames, and local users will be able to connect with the full user@dbname, and we can allow user@ as a shortcut. In summary, I prefer to change the code to have local users append the '@'. Comments? It is an easy change and prevents what is a very confusing situation where we add '@' for users who don't have @, and remove '@' for users who have it. --------------------------------------------------------------------------- Peter Eisentraut wrote: > Tom Lane writes: > > > Peter Eisentraut <peter_e@gmx.net> writes: > > > I'm concerned that we leave essentially no migration path, that is, the > > > ability to turn the feature on to try it out without immediately breaking > > > every application. > > > > Uh ... what? I fail to understand your objection. AFAICS the only > > apps that could be "broken" are scripts that have usernames hardwired > > into them ... > > I'm completely lost between all the proposals about where the @ is going > to be specified, added, or removed. What happens on the client side and > what happens on the server side? > > All I would like to see is that I can turn on this feature and nothing > changes as long as I don't add any "local users". Yes, that includes > hard-wired user names on the client side. Of course there are various > degrees of hard-wiring, but what if the ISP admin updates to 7.3 and wants > to turn on the feature for new clients? Does he tell all his existing > clients that they must update their user names? Possibly, these users got > their database access with a shell account and don't specify the user name > at all because it defaults to the OS user name. Does that continue to > work? > > -- > Peter Eisentraut peter_e@gmx.net > > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
On Tuesday 27 August 2002 03:19 pm, Bruce Momjian wrote: > I think we need to resolve this discussion from a week ago. The current > code is this: I thought it WAS resolved, to do: > global usernames are stored just like before, e.g. postgres > local users are stored as user@dbname > when connecting, global users add '@' to their names > when connecting, local users use just their user name, no @dbname > Tom likes this because it is the fewer global users who have to append > the '@'. At least that was my perception of the uneasy consensus reached. Basically, this tags the @ as magic saying, during the client connect process, 'I'm GLOBAL, treat me differently'. Now that I actually understand how this is supposed to work, which your four lines above elucidate nicely, I am in more agreement than I was that this is the right answer to this issue. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Lamar Owen wrote: > On Tuesday 27 August 2002 03:19 pm, Bruce Momjian wrote: > > I think we need to resolve this discussion from a week ago. The current > > code is this: > > I thought it WAS resolved, to do: > > > global usernames are stored just like before, e.g. postgres > > local users are stored as user@dbname > > when connecting, global users add '@' to their names > > when connecting, local users use just their user name, no @dbname > > > Tom likes this because it is the fewer global users who have to append > > the '@'. > > At least that was my perception of the uneasy consensus reached. > > Basically, this tags the @ as magic saying, during the client connect process, > 'I'm GLOBAL, treat me differently'. Now that I actually understand how this > is supposed to work, which your four lines above elucidate nicely, I am in > more agreement than I was that this is the right answer to this issue. OK, you have now split the vote because we have two for the change, and two against. Why do you prefer to tag the globals? Is it Tom's argument? I think it is kind of strange to tag the globals when it is the locals who have @ in their username, and when they do: $ psql -U dave testWelcome to psql 7.3devel, the PostgreSQL interactive terminal.Type: \copyright for distribution terms \h for help with SQL commands \? for help on internal slash commands \g or terminate with semicolonto execute query \q to quittest=> select current_user; current_user -------------- dave@test(1 row) they will see their full username. I can go either way. I am just saying we need to hear from more people to make sure we are doing this properly. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I can go either way. I am just saying we need to hear from more people
> to make sure we are doing this properly.
Likewise. In particular I'd like to hear from Marc, who after all
is the one who caused us to consider this hack in the first place.
Does it satisfy his requirement? Is one way or the other preferable
for his actual usage?
regards, tom lane
On Tuesday 27 August 2002 03:43 pm, Bruce Momjian wrote: > Lamar Owen wrote: > > On Tuesday 27 August 2002 03:19 pm, Bruce Momjian wrote: > > I thought it WAS resolved, to do: > > > Tom likes this because it is the fewer global users who have to append > > > the '@'. > > At least that was my perception of the uneasy consensus reached. > OK, you have now split the vote because we have two for the change, and > two against. Why do you prefer to tag the globals? Is it Tom's > argument? I think it is kind of strange to tag the globals when it is > the locals who have @ in their username, and when they do: I agree with what Tom said, and understand why he said it. And I thought you did, too -- I have apparently misunderstood (again!) the issue. In the local-enabled scheme, ISTM the majority of users will be local users. The goal is transparent virtual databases -- at least that's what I consider the goal. As far as the user is concerned, the other databases might as well not even exist -- all they are doing is connecting to their database. Since they have to give the database name as part of the connection, it just makes sense that they should have the closest to default behavior. In the case of a virtual hosting postmaster, global users would likely be DBA's, although they might not be. These users are going to be the exception, not the rule -- thus a character to tag their 'exceptional' nature. You may not even want your virtual host local users to realize that there is another user by that name. Thus, the standard notation is the least intrusive for the very users that need uninstrusive notation. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
It should also be noted that it's easy to get the DBAs to change their username in the future when / if the @ hack goes away BUT it will be difficult to change the usernames of the hundreds to thousands of customer accounts. For an upgrade, we'd end up making a script in the upgrade to keep them the same (with the @) then have a control panel code in place to suggest to the user that they may stop using the @ if they wish <click here> type of thing. > > > > Tom likes this because it is the fewer global users who have to append > > > > the '@'. > > > > At least that was my perception of the uneasy consensus reached. > > > OK, you have now split the vote because we have two for the change, and > > two against. Why do you prefer to tag the globals? Is it Tom's > > argument? I think it is kind of strange to tag the globals when it is > > the locals who have @ in their username, and when they do: > In the case of a virtual hosting postmaster, global users would likely be > DBA's, although they might not be. These users are going to be the > exception, not the rule -- thus a character to tag their 'exceptional' > nature.
Lamar Owen wrote: > On Tuesday 27 August 2002 03:43 pm, Bruce Momjian wrote: > > Lamar Owen wrote: > > > On Tuesday 27 August 2002 03:19 pm, Bruce Momjian wrote: > > > I thought it WAS resolved, to do: > > > > > Tom likes this because it is the fewer global users who have to append > > > > the '@'. > > > > At least that was my perception of the uneasy consensus reached. > > > OK, you have now split the vote because we have two for the change, and > > two against. Why do you prefer to tag the globals? Is it Tom's > > argument? I think it is kind of strange to tag the globals when it is > > the locals who have @ in their username, and when they do: > > I agree with what Tom said, and understand why he said it. And I thought you > did, too -- I have apparently misunderstood (again!) the issue. I try not to interject my opinions into emails where I am asking for disucsion so people can more clearly see the options and vote accordingly. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
OK, we have enough votes to keep the existing behavior, unless Marc appears and says he doesn't like it. ;-) Thanks. --------------------------------------------------------------------------- Rod Taylor wrote: > It should also be noted that it's easy to get the DBAs to change their > username in the future when / if the @ hack goes away BUT it will be > difficult to change the usernames of the hundreds to thousands of > customer accounts. > > For an upgrade, we'd end up making a script in the upgrade to keep them > the same (with the @) then have a control panel code in place to suggest > to the user that they may stop using the @ if they wish <click here> > type of thing. > > > > > > > Tom likes this because it is the fewer global users who have to append > > > > > the '@'. > > > > > > At least that was my perception of the uneasy consensus reached. > > > > > OK, you have now split the vote because we have two for the change, and > > > two against. Why do you prefer to tag the globals? Is it Tom's > > > argument? I think it is kind of strange to tag the globals when it is > > > the locals who have @ in their username, and when they do: > > > In the case of a virtual hosting postmaster, global users would likely be > > DBA's, although they might not be. These users are going to be the > > exception, not the rule -- thus a character to tag their 'exceptional' > > nature. > > > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
On Tue, 2002-08-27 at 21:05, Lamar Owen wrote: > On Tuesday 27 August 2002 03:43 pm, Bruce Momjian wrote: > > Lamar Owen wrote: > > > On Tuesday 27 August 2002 03:19 pm, Bruce Momjian wrote: > > > I thought it WAS resolved, to do: > > > > > Tom likes this because it is the fewer global users who have to append > > > > the '@'. > > > > At least that was my perception of the uneasy consensus reached. > > > OK, you have now split the vote because we have two for the change, and > > two against. Why do you prefer to tag the globals? Is it Tom's > > argument? I think it is kind of strange to tag the globals when it is > > the locals who have @ in their username, and when they do: > > I agree with what Tom said, and understand why he said it. And I thought you > did, too -- I have apparently misunderstood (again!) the issue. > > In the local-enabled scheme, ISTM the majority of users will be local users. > The goal is transparent virtual databases -- at least that's what I consider > the goal. As far as the user is concerned, the other databases might as well > not even exist -- all they are doing is connecting to their database. Since > they have to give the database name as part of the connection, it just makes > sense that they should have the closest to default behavior. > > In the case of a virtual hosting postmaster, global users would likely be > DBA's, although they might not be. These users are going to be the > exception, not the rule -- thus a character to tag their 'exceptional' > nature. > > You may not even want your virtual host local users to realize that there is > another user by that name. Thus, the standard notation is the least > intrusive for the very users that need uninstrusive notation. Has this behaviour been carried through into GRANT and REVOKE? If the object is transparency for local users, it should be possible in database "test" to say "GRANT ... TO fred" and have "fred" understood as "fred@test". If that is the case, then I will support the current position. It follows from the objective of transparency that, when reporting a user name, local users should be reported without the database suffix, i.e., "fred" not "fred@test". Global users should be reported with the trailing "@". This should cause no problem, because we have no cross-database communication; it should be impossible for "george@dummy" to have any connection with database "test". -- Oliver Elphick Oliver.Elphick@lfix.co.uk Isle of Wight, UK http://www.lfix.co.uk/oliver GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C ======================================== "But the end of all things is at hand; be ye therefore sober, and watch untoprayer. And above all things have fervent love among yourselves; for love shall cover the multitude of sins." I Peter 4:7,8
Oliver Elphick wrote: > > I agree with what Tom said, and understand why he said it. And I thought you > > did, too -- I have apparently misunderstood (again!) the issue. > > > > In the local-enabled scheme, ISTM the majority of users will be local users. > > The goal is transparent virtual databases -- at least that's what I consider > > the goal. As far as the user is concerned, the other databases might as well > > not even exist -- all they are doing is connecting to their database. Since > > they have to give the database name as part of the connection, it just makes > > sense that they should have the closest to default behavior. > > > > In the case of a virtual hosting postmaster, global users would likely be > > DBA's, although they might not be. These users are going to be the > > exception, not the rule -- thus a character to tag their 'exceptional' > > nature. > > > > You may not even want your virtual host local users to realize that there is > > another user by that name. Thus, the standard notation is the least > > intrusive for the very users that need uninstrusive notation. > > Has this behaviour been carried through into GRANT and REVOKE? If the > object is transparency for local users, it should be possible in > database "test" to say "GRANT ... TO fred" and have "fred" understood as > "fred@test". No changes have been made anywhere except for the username passed by the client. All reporting of user names and all administration go by their full pg_shadow username, so global user dave@ is dave in pg_shadow, and dave is dave@db1 in pg_shadow. One goal of this patch was a small footprint. > If that is the case, then I will support the current position. > > > It follows from the objective of transparency that, when reporting a > user name, local users should be reported without the database suffix, > i.e., "fred" not "fred@test". Global users should be reported with the > trailing "@". This should cause no problem, because we have no > cross-database communication; it should be impossible for "george@dummy" > to have any connection with database "test". Nope, none of this is done and I don't think there is a demand to do it. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian writes: > global usernames are stored just like before, e.g. postgres > local users are stored as user@dbname > when connecting, global users add '@' to their names > when connecting, local users use just their user name, no @dbname I'm OK with this in principle. But I must say I was quite confused because the "@" symbol appears in diametrically opposite contexts: a) designate local users on the server b) designate global users in the client Perhaps I might have been less confused if meaning (b) used a different character, say "username!". This might be equally confusing to the next person -- just my observation. -- Peter Eisentraut peter_e@gmx.net
On Tue, 2002-08-27 at 22:11, Bruce Momjian wrote: > Oliver Elphick wrote: > > Has this behaviour been carried through into GRANT and REVOKE? If the > > object is transparency for local users, it should be possible in > > database "test" to say "GRANT ... TO fred" and have "fred" understood as > > "fred@test". > > No changes have been made anywhere except for the username passed by the > client. All reporting of user names and all administration go by their > full pg_shadow username, so global user dave@ is dave in pg_shadow, and > dave is dave@db1 in pg_shadow. One goal of this patch was a small > footprint. That is understandable, but it means that there is an inconsistency of usage for _every_ user. You connect as "postgres@" and "fred", but for all other purposes - CREATE USER, GRANT, REVOKE, CURRENT_USER, etc. you will be "postgres" and "fred@database". This seems likely to cause users confusion, don't you think? It also means that any applications which test usernames will have to be altered to strip off the "@database". So it seems to me that you have achieved a small footprint within the code, but potentially at the cost of a larger impact on users. -- Oliver Elphick Oliver.Elphick@lfix.co.uk Isle of Wight, UK http://www.lfix.co.uk/oliver GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C ======================================== "But the end of all things is at hand; be ye therefore sober, and watch untoprayer. And above all things have fervent love among yourselves; for love shall cover the multitude of sins." I Peter 4:7,8
Oliver Elphick <olly@lfix.co.uk> writes:
> So it seems to me that you have achieved a small footprint within the
> code, but potentially at the cost of a larger impact on users.
I don't think anyone will deny that this is a kluge. However, we are
not going to resurrect the separate-password-file thing (that was a
worse kluge, especially when used for this purpose), and we are not
going to postpone 7.3 while we think about a nicer solution. So, simple
is beautiful for now. If there are enough people actually *using* this
feature to make it worth improving, we can improve it ... later.
regards, tom lane
Peter Eisentraut <peter_e@gmx.net> writes:
> Perhaps I might have been less confused if meaning (b) used a different
> character, say "username!".
Well, maybe ... but do we want to create two special characters in
usernames, instead of one? @ still has to be considered special in
incoming usernames, else you have no security against local users
connecting to other databases.
regards, tom lane
On Tue, 2002-08-27 at 22:44, Tom Lane wrote: > Oliver Elphick <olly@lfix.co.uk> writes: > > So it seems to me that you have achieved a small footprint within the > > code, but potentially at the cost of a larger impact on users. > > I don't think anyone will deny that this is a kluge. However, we are > not going to resurrect the separate-password-file thing (that was a > worse kluge, especially when used for this purpose), and we are not > going to postpone 7.3 while we think about a nicer solution. So, simple > is beautiful for now. If there are enough people actually *using* this > feature to make it worth improving, we can improve it ... later. Could we then have a TODO item: * Make local and global user representation consistent throughout. -- Oliver Elphick Oliver.Elphick@lfix.co.uk Isle of Wight, UK http://www.lfix.co.uk/oliver GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C ======================================== "But the end of all things is at hand; be ye therefore sober, and watch untoprayer. And above all things have fervent love among yourselves; for love shall cover the multitude of sins." I Peter 4:7,8
Oliver Elphick <olly@lfix.co.uk> writes:
> This should cause no problem, because we have no
> cross-database communication; it should be impossible for "george@dummy"
> to have any connection with database "test".
Not so; you need look no further than the owner column of pg_database
to find a case where people can see usernames that might be local to
other databases. Group membership lists might well contain users
from multiple databases, too.
regards, tom lane
Oliver Elphick <olly@lfix.co.uk> writes:
> Could we then have a TODO item:
> * Make local and global user representation consistent throughout.
That's hardly an appropriately expansive TODO item. I prefer
* Provide a real solution for database-local users
;-)
regards, tom lane
Tom Lane wrote: > Oliver Elphick <olly@lfix.co.uk> writes: > > Could we then have a TODO item: > > * Make local and global user representation consistent throughout. > > That's hardly an appropriately expansive TODO item. I prefer > > * Provide a real solution for database-local users I say let's get it out in the field and see what people ask for. For all we know, they may be very happy with this, nor not use it at all. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Peter Eisentraut wrote: > Bruce Momjian writes: > > > global usernames are stored just like before, e.g. postgres > > local users are stored as user@dbname > > when connecting, global users add '@' to their names > > when connecting, local users use just their user name, no @dbname > > I'm OK with this in principle. But I must say I was quite confused > because the "@" symbol appears in diametrically opposite contexts: > > a) designate local users on the server > > b) designate global users in the client > > Perhaps I might have been less confused if meaning (b) used a different > character, say "username!". This might be equally confusing to the next > person -- just my observation. There is no question it is 100% confusing. You are not alone. What keeps us from unconfusing it is the desire to make local usernames clean looking, I think. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
On Tue, 2002-08-27 at 23:10, Tom Lane wrote: > Oliver Elphick <olly@lfix.co.uk> writes: > > This should cause no problem, because we have no > > cross-database communication; it should be impossible for "george@dummy" > > to have any connection with database "test". > > Not so; you need look no further than the owner column of pg_database > to find a case where people can see usernames that might be local to > other databases. Group membership lists might well contain users > from multiple databases, too. I suspect I have a different view of the ultimate aim of this feature. If we go to a thorough solution for virtual local databases, local users of other databases ought to be completely invisible. I suppose that means that to a local user, pg_database would be a view showing only template[01] and the local database. pg_shadow, too, would show only global users and local users in the same database. I can't see how a group within a local database could contain users from other databases. In the context in which this is being used, each database belongs to a different customer; each database needs to be invisible to other customers. How then should it be possible to have group lists containing users from different local databases? Groups should be local as well as users. Perhaps I like complicating things too much... -- Oliver Elphick Oliver.Elphick@lfix.co.uk Isle of Wight, UK http://www.lfix.co.uk/oliver GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C ======================================== "Use hospitality one to another without grudging." I Peter 4:9
Oliver Elphick <olly@lfix.co.uk> writes:
> If we go to a thorough solution for virtual local databases, local users
> of other databases ought to be completely invisible.
Perhaps. I'm not convinced of that, but it's a defensible position.
> I can't see how a group within a local database could contain users from
> other databases.
This presupposes that groups become local to databases, which is not
a foregone conclusion in my mind at all. Perhaps we'll need to invent
the concept of local and global groups, to go along with local and
global users.
Anyway, this is all designing far in advance of available use-cases.
Marc was satisfying his needs (so far as he said, anyway) with a
password-based scheme even klugier than what we're going to put in 7.3.
We don't have other usage examples at all. And with the availability
of schemas in 7.3, I think that multiple databases per installation
is going to become less common to begin with --- people will more often
use multiple schemas in one big database if they want the option of
data sharing, or completely separate installations if they want airtight
separation.
Accordingly, I'm disinclined to start actually inventing features in
this area until I see more evidence that it's worth the trouble.
regards, tom lane