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 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
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, Pennsylvania 19026
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, Pennsylvania 19026Bruce 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, Pennsylvania 19026Bruce 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.
Import Notes
Resolved by subject fallback
* 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:
Show quoted text
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
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?
--
Brett Schwarz
brett_schwarz AT yahoo.com
Import Notes
Reply to msg id not found: 20020731132220.C7595@mail.libertyrms.comReference msg id not found: 28268.1028127945@sss.pgh.pa.usReference msg id not found: 20020731134532.O83339-100000@mail1.hub.orgReference msg id not found: 20020731132220.C7595@mail.libertyrms.com | Resolved by subject fallback
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
Attachments:
Import Notes
Resolved by subject fallback
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
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 x110On 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, Pennsylvania 19026Tom 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, Pennsylvania 19026Bruce 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 defaultI 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, Pennsylvania 19026If 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... */
#endifLet 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 19026Neil 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, Pennsylvania 19026Christopher 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 loading
7.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, Pennsylvania 19026Thomas 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, Pennsylvania 19026Neil 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, Pennsylvania 19026Marc 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.4Then, 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, Pennsylvania 19026Added 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, Pennsylvania 19026psql 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
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 defaultI 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, Pennsylvania 19026Tom 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, Pennsylvania 19026As 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
Import Notes
Resolved by subject fallback
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, Pennsylvania 19026Ron 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, Pennsylvania 19026
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
Import Notes
Resolved by subject fallback
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, Pennsylvania 19026Yes, 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
Import Notes
Resolved by subject fallback
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, Pennsylvania 19026Mentioning 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, Pennsylvania 19026On 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, Pennsylvania 19026On 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, Pennsylvania 19026On 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, Pennsylvania 19026On 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, Pennsylvania 19026On 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, Pennsylvania 19026On 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, Pennsylvania 19026On 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 weekCluster 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, Pennsylvania 19026
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.
Import Notes
Reply to msg id not found: 20020731231230.93B2FEE0C19@relay2.pgsql.comReference msg id not found: 20020731231230.93B2FEE0C19@relay2.pgsql.com | Resolved by subject fallback
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 weekCluster 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 19026Attachments:
/pgpatches/dbusertext/plainDownload
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. */
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.4Then, 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
* 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 ...
-----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 itemspsql 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.
Import Notes
Resolved by subject fallback
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
Import Notes
Resolved by subject fallback
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, Pennsylvania 19026On 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, Pennsylvania 19026Marc 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, Pennsylvania 19026On 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, Pennsylvania 19026I 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.
Show quoted text
-----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 itemsIf 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... */
#endifLet 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
Import Notes
Resolved by subject fallback
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, 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, Pennsylvania 19026Peter 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.guestI 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, Pennsylvania 19026Peter 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, Pennsylvania 19026On 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.guestI 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, Pennsylvania 19026
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's pg_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
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-added
2) the new prefixing of the database name to the username when enabled
3) 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?
--
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 19026OK, 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
Show quoted text
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 nothingIf 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 nothingIf 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, Pennsylvania 19026Bruce 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 Marc actually
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's unreasonable
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 compelling reason why we
*need* this feature in the standard distribution, I'd rather
we not go back to the old way of doing things.
- I'm not perfectly happy with the scheme Bruce suggested as
an interim fix (#2). If we're going to implement this
feature, let's do it properly. In particular, I'm not
convinced that this feature is urgently needed enough to
justify a short-term kludge, and I dislike using a GUC
variable to toggle between two 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
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 nothingI 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
-----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 itemsIt 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.
Import Notes
Resolved by subject fallback
- 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
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 nothingI 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
Import Notes
Reply to msg id not found: 20020807192641.T68908-100000@mail1.hub.orgReference msg id not found: 20020807192641.T68908-100000@mail1.hub.org | Resolved by subject fallback
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 nothingI 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, Pennsylvania 19026On 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 nothingI 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)
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
Show quoted text
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, Pennsylvania 19073
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.comIf 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, Pennsylvania 19073Some 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.comIf people are worried about the sorting, ORDER BY domain, username.
My $0.02. -scWell, 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, Pennsylvania 19073OK, 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 19073Attachments:
/bjm/difftext/plainDownload
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. */
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. -scI 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 <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
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
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. -scI 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, Pennsylvania 19073On 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.comWhat 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
Import Notes
Reply to msg id not found: 20020814074546.GF61893@ninja1.internal
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
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.comWhat 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 %.
Show quoted text
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.comWhat 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 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())?
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 x110On 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. 1Should 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
Import Notes
Reply to msg id not found: 001201c243202e0020d064c8a8c0@balefire10ww
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, Pennsylvania 19073Bruce 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, Pennsylvania 19073This 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, Pennsylvania 19073Bruce 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.
Show quoted text
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, Pennsylvania 19073Bruce 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, Pennsylvania 19073On 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 at Pop4 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-test
maillabels
testing2
template1
template0
pari
(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, Pennsylvania 19073On 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, Pennsylvania 19073On 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 at Pop4 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, Pennsylvania 19073Bruce 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, Pennsylvania 19073Bruce 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 at Pop4 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, Pennsylvania 19073pgman@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
Show quoted text
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?
--
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 19073Attachments:
/pgpatches/dbusertext/plainDownload
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 at Pop4 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 -0400
Subject: Re: [HACKERS] Open 7.3 items
To: 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-20020517
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org
X-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, Pennsylvania 19073Vince 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, Pennsylvania 19073On 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 at Pop4 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 at Pop4 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, Pennsylvania 19073On 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 at Pop4 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 at Pop4 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 at Pop4 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 19073Attachments:
/pgpatches/dbusertext/plainDownload
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 at Pop4 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 at Pop4 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, Pennsylvania 19073I 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, Pennsylvania 19073On 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 at Pop4 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 at Pop4 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 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? 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 = trueMy 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 feature
multiple global users
no namespace collisions between global/non-global users
zero performance impact
32-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, Pennsylvania 19073Bruce 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 at Pop4 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, Pennsylvania 19073On 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 = trueMy 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 at Pop4 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 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
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, Pennsylvania 19073
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 Father may 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, Pennsylvania 19073OK, 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 19073Attachments:
/pgpatches/dbusertext/plainDownload
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 test
psql: FATAL: user "postgres@test" does not exist
$ psql -U postgres@ test
Welcome 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 semicolon to execute query
\q to quit
test=>
---------------------------------------------------------------------------
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 19073OK, 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, Pennsylvania 19073Bruce 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, Pennsylvania 19073Bruce 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, Pennsylvania 19073Tom 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 at Pop4 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 at Pop4 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 (else what 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:
Show quoted text
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. 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 '@'.
Vince and Peter think that it should be local users adding '@' when
connecting because:
they have an @ sign in their name anyway
global 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, Pennsylvania 19073On 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 @dbnameTom 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 test
Welcome 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 semicolon to execute query
\q to quit
test=> 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, Pennsylvania 19073Bruce 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.
Show quoted text
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.
Yes, this is the counter case, where the '@' disappears; so it appears
magically for local users, and disappears for global users.
---------------------------------------------------------------------------
Robert Treat wrote:
Is the converse to this:
$ psql -U postgres@ test
Welcome 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 semicolon to execute query
\q to quittest=> select current_user;
current_user
--------------
postgres
(1 row)this seems counterintuitive to me, so I'd like to see the strong
practical application that makes it necessary. (This is where mark comes
in I suppose)Robert Treat
On Tue, 2002-08-27 at 15:43, Bruce Momjian wrote:
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 @dbnameTom 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 test
Welcome 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 semicolon to 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, Pennsylvania 19073---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
--
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 19073Import Notes
Reply to msg id not found: 1030479147.1825.4.camel@camel | Resolved by subject fallback
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, Pennsylvania 19073OK, 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, Pennsylvania 19073On 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 unto prayer. 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, Pennsylvania 19073On 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 unto prayer. And above all things
have fervent love among yourselves; for love shall
cover the multitude of sins." I Peter 4:7,8
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
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 unto prayer. 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, Pennsylvania 19073Peter 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 @dbnameI'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, Pennsylvania 19073On 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
Tom Lane: "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."
This is not a good assumption, in my opinion. Normally, one app is
associated with one database. This way, if something happens to the db,
only one application is unavailable, others will not be affected, more
or less. Besides, some databases are huge, so recovery time may take a
long time. If everything is in one db, the whole organization will be
brought to a halt, all apps will be down for a while. From my
experience, this will not be considered acceptable in any reasonable
organization.
This is the place where cross-db queries become critically important.
You do not want to duplicate data in several databases and, at the same
time, you do not want to have one huge unmanageable db that can
potentially bring down all your apps.
my $0.02
__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com
Import Notes
Resolved by subject fallback