Thread: Open 7.3 items

Open 7.3 items

From

Bruce Momjian

Date:

31 July 2002, 02:50:39

Here are the open items for 7.3.  We have one more month to address them
before beta.

---------------------------------------------------------------------------
                             P O S T G R E S Q L
                         7 . 3  O P E N    I T E M S


Current at ftp://candle.pha.pa.us/pub/postgresql/open_items.

Source Code Changes
-------------------
Socket permissions - only install user can access db by defaultunix_socket_permissions in postgresql.conf
NAMEDATALEN - disk/performance penalty for increase, 64, 128?
FUNC_MAX_ARGS - disk/performance penalty for increase, 24, 32?
Point-in-time recovery - ready for 7.3?
Allow easy display of usernames in a group (pg_hba.conf uses groups now)
Reindex/btree shrinkage - does reindex need work, can btree be shrunk?
DROP COLUMN - ready?
CLUSTER - ready?
display locks - ready?
Win32 - timefame?
Prepared statements - ready?
Schema handling - ready? interfaces? client apps?
Dependency - pg_dump auto-create dependencies for 7.2.X data? 
glibc and mktime() - fix?
Functions Returning Sets - done?
ecpg and bison issues - solved?


Documentation Changes
---------------------


--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026

Re: Open 7.3 items

From

"Christopher Kings-Lynne"

Date:

31 July 2002, 03:00:19

> 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

Re: Open 7.3 items

From

Lamar Owen

Date:

31 July 2002, 03:05:31

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

Re: Open 7.3 items

From

Bruce Momjian

Date:

31 July 2002, 03:19:03

Lamar Owen wrote:
> On Tuesday 30 July 2002 11:50 pm, Bruce Momjian wrote:
> > Here are the open items for 7.3.  We have one more month to address them
> > before beta.
> 
> > Source Code Changes
> > -------------------
> 
> Bruce, is the config file location stuff not being addressed?  I remember Mark 
> (mlw) had worked up the patch for a '-C' switch, there was discussion, etc.  
> Did it not make the todo?  
> 
> If Peter or someone else doesn't beat me to it I might try my hand at that 
> one, as I would dearly love to be able to decouple the config files from 
> PGDATA.  It has been discussed; consensus was not reached as I recall.

The issue was never resolved, so it did not make any lists.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026

Re: Open 7.3 items

From

Tom Lane

Date:

31 July 2002, 03:19:29

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

Re: Open 7.3 items

From

Bruce Momjian

Date:

31 July 2002, 03:22:29

Tom Lane wrote:
> Lamar Owen <lamar.owen@wgcr.org> writes:
> > Bruce, is the config file location stuff not being addressed? ...
> > If Peter or someone else doesn't beat me to it I might try my hand at that 
> > one, as I would dearly love to be able to decouple the config files from 
> > PGDATA.  It has been discussed; consensus was not reached as I recall.
> 
> I believe that last part was the sticking point.  If you can find some
> consensus on how it ought to work, then go for it.  My own opinion is
> that there is nothing broken there; certainly nothing so broken that
> we need to force a change under schedule pressure.

I don't feel we are under pressure.  We have time to discuss and address
it.


--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026

Re: Open 7.3 items

From

Tom Lane

Date:

31 July 2002, 03:29:17

Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> ... My own opinion is
>> that there is nothing broken there; certainly nothing so broken that
>> we need to force a change under schedule pressure.

> I don't feel we are under pressure.  We have time to discuss and address
> it.

Well, it's all a matter of how you look at it.  Isn't the point of your
post that began this thread to start giving people a sense of time
pressure?

I agree that if we could quickly come to a resolution about how this
ought to work, there's plenty of time to go off and implement it.  But
(1) we failed to come to a consensus before, so I'm not optimistic
than one will suddenly emerge now; (2) we've got a ton of other issues
that we *need* to deal with before beta.  This one does not strike me
as a must-fix, and so I'm loathe to spend much development time on it
when there are so many open issues.
        regards, tom lane

Re: Open 7.3 items

From

Bruce Momjian

Date:

31 July 2002, 03:35:32

Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Tom Lane wrote:
> >> ... My own opinion is
> >> that there is nothing broken there; certainly nothing so broken that
> >> we need to force a change under schedule pressure.
> 
> > I don't feel we are under pressure.  We have time to discuss and address
> > it.
> 
> Well, it's all a matter of how you look at it.  Isn't the point of your
> post that began this thread to start giving people a sense of time
> pressure?
> 
> I agree that if we could quickly come to a resolution about how this
> ought to work, there's plenty of time to go off and implement it.  But
> (1) we failed to come to a consensus before, so I'm not optimistic
> than one will suddenly emerge now; (2) we've got a ton of other issues
> that we *need* to deal with before beta.  This one does not strike me
> as a must-fix, and so I'm loathe to spend much development time on it
> when there are so many open issues.

Well, it is up to the individuals involved.  If someone wants to deal
with it, and gets a consensus, and comes up with a patch, let them.

The list is for time pressure on those items.  It does not affect new
items.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026

Re: Open 7.3 items

From

Tom Lane

Date:

31 July 2002, 03:50:18

Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Here are the open items for 7.3.

Some comments ...

> Socket permissions - only install user can access db by default

I do not agree with this goal.

> NAMEDATALEN - disk/performance penalty for increase, 64, 128?
> FUNC_MAX_ARGS - disk/performance penalty for increase, 24, 32?

At the moment I don't see a lot of solid evidence that increasing
NAMEDATALEN has any performance penalty.  Someone reported about
a 10% slowdown on pgbench with NAMEDATALEN=128 ... but Neil Conway
tried to reproduce the result, and got about a 10% *speedup*.
Personally I think 10% is well within the noise spectrum for
pgbench, and so it's difficult to claim that we have established
any performance difference at all.  I have not tried to measure
FUNC_MAX_ARGS differences.

> Point-in-time recovery - ready for 7.3?

At the moment, it doesn't exist at all.  If patches appear, we can
review 'em, but right now there is nothing to debate.

> DROP COLUMN - ready?

I'm on it.

> Win32 - timefame?

I've seen nothing to make me think this will be ready for 7.3.

> Prepared statements - ready?

I think we're close there; the patch seems okay, we're just debating
minor syntax issues.

> Schema handling - ready? interfaces? client apps?

The backend will be ready (it's not quite yet).  pg_dump is ready.
psql is very definitely not ready, nor is pgaccess.  I don't know the
status for JDBC or ODBC; any comments?  The other interface libraries
probably don't care.

> Dependency - pg_dump auto-create dependencies for 7.2.X data?

Huh?

> glibc and mktime() - fix?

We need a fix for this.  Dunno what to do about it.

> ecpg and bison issues - solved?

Not yet :-(.  Anyone have a line into the bison project?

Other things on my radar screen:

* I have about zero confidence in the recent tuple-header-size-reduction
patches.

* pg_conversion stuff --- do we understand this thing's behavior under
failure conditions?  Does it work properly with namespaces and
dependencies?

* pg_dumpall probably ought to dump database privilege settings, also
per-user and per-database GUC settings.

* BeOS and QNX4 ports are busted.

* The whole area of which implicit coercions should be allowed is a
serious problem that we have not spent enough time on.  There are
a number of cases in which CVS tip is clearly broken compared to
prior releases.

* Bear Giles' SSL patches seem to be causing unhappiness in some
quarters.

* libpqxx is not integrated into build process nor docs.  It should
be integrated or reversed out before beta.
        regards, tom lane

Re: Open 7.3 items

From

"Dann Corbit"

Date:

31 July 2002, 03:53:54

> -----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.

Re: Open 7.3 items

From

Tatsuo Ishii

Date:

31 July 2002, 04:00:36

> * 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

Re: Open 7.3 items

From

"Marc G. Fournier"

Date:

31 July 2002, 04:01:44

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
>

Trim the Fat (Was: Re: Open 7.3 items )

From

"Marc G. Fournier"

Date:

31 July 2002, 04:11:08

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' ...

Re: Open 7.3 items

From

"Christopher Kings-Lynne"

Date:

31 July 2002, 04:19:13

> > 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

Re: Open 7.3 items

From

Thomas Lockhart

Date:

31 July 2002, 05:24:34

...
> 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

Re: Open 7.3 items

From

"Kaare Rasmussen"

Date:

31 July 2002, 06:06:21

>> 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

Re: Open 7.3 items

From

Jean-Michel POURE

Date:

31 July 2002, 11:53:14

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

Re: Trim the Fat (Was: Re: Open 7.3 items )

From

nconway@klamath.dyndns.org (Neil Conway)

Date:

31 July 2002, 13:54:57

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

Re: Trim the Fat (Was: Re: Open 7.3 items )

From

Tom Lane

Date:

31 July 2002, 14:05:48

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

Re: Open 7.3 items

From

nconway@klamath.dyndns.org (Neil Conway)

Date:

31 July 2002, 14:19:18

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

Re: Open 7.3 items

From

nconway@klamath.dyndns.org (Neil Conway)

Date:

31 July 2002, 14:26:13

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

Re: Open 7.3 items

From

Tom Lane

Date:

31 July 2002, 14:31:14

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

Re: Trim the Fat (Was: Re: Open 7.3 items )

From

"Marc G. Fournier"

Date:

31 July 2002, 15:45:08

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 ...

Re: Open 7.3 items

From

Ron Snyder

Date:

31 July 2002, 16:01:03

> > 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

Attachment

pgdump-tmp-table-test.sh

Re: Trim the Fat (Was: Re: Open 7.3 items )

From

"Marc G. Fournier"

Date:

31 July 2002, 16:08:37

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 ...

Re: Open 7.3 items

From

"Marc G. Fournier"

Date:

31 July 2002, 16:10:23

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 :(

Re: Trim the Fat (Was: Re: Open 7.3 items )

From

Andrew Sullivan

Date:

31 July 2002, 16:22:21

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

Re: Trim the Fat (Was: Re: Open 7.3 items )

From

Brett Schwarz

Date:

31 July 2002, 16:35:19

I too do not like alot of bloat in the distribution, but I also agree
with what Andrew is saying.

Currently, at the FTP site, you can download the whole tar file, or in 4
separate tarballs. How hard would it be to create a separate tarball for
client related packages? I am not sure if this would be a *great*
solution, but it might be a good compromise.
   --brett


On Wed, 2002-07-31 at 10:22, Andrew Sullivan wrote:
> On Wed, Jul 31, 2002 at 02:08:33PM -0300, Marc G. Fournier wrote:
> > On Wed, 31 Jul 2002, Tom Lane wrote:
> 
> > > One reason for wanting to integrate libpqxx is that I don't think we'll
> > > find out anything about its portability until we get a lot of people
> > > trying to build it.  If it's a separate distro that won't happen quickly.
> > 
> > Who cares?  Those that need a C++ interface will know where to find it,
> > and will report bugs that they have ... why should it be tested on every
> > platform when we *might* only have those on the Linux platform using it?
> 
> This seems a bad argument.  You can't say "we support interface xyz"
> and never test it on anything except i80x86 Linux.  Somebady comes
> along and tries to make it go on Solaris, and it doesn't work: poof,
> the cross-platform reputation that you and other have worked hard to
> burnish goes away.  Never mind that it's only a client library.
> 
> Besides, more generally, Postgres already has a reputation as being
> difficult to install.  The proposal to separate out all the
> "non-basics" (I'm not even sure how one would draw that line: maybe a
> server-only package and a client-library package run through GBorg?)
> would mean that anyone wanting to do something moderately complicated
> would have a yet higher hurdle.  Isn't that a problem?
> 
> A  
> 
> -- 
> ----
> Andrew Sullivan                               87 Mowat Avenue 
> Liberty RMS                           Toronto, Ontario Canada
> <andrew@libertyrms.info>                              M6K 3E3
>                                          +1 416 646 3304 x110
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
> 
> http://archives.postgresql.org
-- 
Brett Schwarz
brett_schwarz AT yahoo.com

Re: Trim the Fat (Was: Re: Open 7.3 items )

From

"Jeff MacDonald"

Date:

31 July 2002, 16:36:46

> 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.

Re: Trim the Fat (Was: Re: Open 7.3 items )

From

"Marc G. Fournier"

Date:

31 July 2002, 17:11:47

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 ...

Re: Trim the Fat (Was: Re: Open 7.3 items )

From

Andrew Sullivan

Date:

31 July 2002, 17:13:11

On Wed, Jul 31, 2002 at 02:36:43PM -0300, Jeff MacDonald wrote:
> 
> When you install freebsd or linux, is it a problem that all the
> perl modules you need have to fetched from cpan ? why can't they
> call just be part of the OS ?'

Well, not just part of the OS, but part of Perl.  And after all, Perl
_does_ include a fabulous variety of built-in modules.

> likewise with dns servers, samba, apache etc.. this is a bit of a stretched
> example
> but the point is the same.

Actually, the comparison is apt.  There's a reason people suggest
using your distribution's PHP or Zope or what-have-you packages,
rather than installing from source: an inexperienced user with these
packages could easily spend several days trying to figure out all the
bits to install.  Obviously, such people are new users, and a
learning curve is expected.  But given recent hand-wringing about the
relative "mind-share" of Postgres &c., it seems perverse to make a
new user have to find out (probably by asking on a mailing list) that
basic stuff like client libraries are a whole separate package, which
needs to be dealt with separately.  It _would_ be nice, though, to be
able to get just the client stuff for sure.  And maybe the separation
is worth it; I just want to be sure that people know the effect on
users.

A

-- 
----
Andrew Sullivan                               87 Mowat Avenue 
Liberty RMS                           Toronto, Ontario Canada
<andrew@libertyrms.info>                              M6K 3E3                                        +1 416 646 3304
x110

Re: Trim the Fat (Was: Re: Open 7.3 items )

From

Andrew Sullivan

Date:

31 July 2002, 17:18:50

On Wed, Jul 31, 2002 at 03:11:40PM -0300, Marc G. Fournier wrote:

> hassle?  Everyone is arguing 'why mysql vs pgsql?' ... if we had a simple
> 'libpq.tar.gz' that could be downloaded, nice and small, then we've just
> made enabling PgSQL by default in mod_php4 brain dead ...

Sorry, I think I wasn't making myself clear.  I think that's a
splendid idea.  But I'm not sure it's worth paying for it by making
users who want the whole thing download multiple packages.  Maybe I'm
alone in thinking that, however, and it's not like I feel terribly
strongly about it.

A

-- 
----
Andrew Sullivan                               87 Mowat Avenue 
Liberty RMS                           Toronto, Ontario Canada
<andrew@libertyrms.info>                              M6K 3E3                                        +1 416 646 3304
x110

Re: Trim the Fat (Was: Re: Open 7.3 items )

From

"Iavor Raytchev"

Date:

31 July 2002, 17:27:27

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'.

Re: Trim the Fat (Was: Re: Open 7.3 items )

From

"Jeff MacDonald"

Date:

31 July 2002, 17:58:42

> 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.

Re: Open 7.3 items

From

Bruce Momjian

Date:

31 July 2002, 18:28:50

Tom Lane wrote:
> > Socket permissions - only install user can access db by default
> 
> I do not agree with this goal.

OK, this is TODO item:

* Make single-user local access permissions the default by limiting permissions on the socket file (Peter E)

Right now, we effectively install initdb as though we are creating a
world-writeable directory on the machine.  (Sure, the directory is
locked down, but by setting PGUSER you can connect to the database as
anyone.)  I don't know any other software that does this, and I can't
see how we can justify the current behavior.

Another idea is to change pg_hba.conf to not default to 'trust' but then
the installing user is going to have to choose a password.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026

Re: Open 7.3 items

From

Bruce Momjian

Date:

31 July 2002, 18:30:36

Tom Lane wrote:
> > NAMEDATALEN - disk/performance penalty for increase, 64, 128?
> > FUNC_MAX_ARGS - disk/performance penalty for increase, 24, 32?
> 
> At the moment I don't see a lot of solid evidence that increasing
> NAMEDATALEN has any performance penalty.  Someone reported about
> a 10% slowdown on pgbench with NAMEDATALEN=128 ... but Neil Conway
> tried to reproduce the result, and got about a 10% *speedup*.
> Personally I think 10% is well within the noise spectrum for
> pgbench, and so it's difficult to claim that we have established
> any performance difference at all.  I have not tried to measure
> FUNC_MAX_ARGS differences.

Yes, we need someone to benchmark both the NAMEDATALEN and FUNC_MAX_ARGS
to prove we are not causing performance problems.  Once that is done,
the default limits can be easily increased.  I was thinking 64 for
NAMEDATALEN and 32 for FUNC_MAX_ARGS, effectively doubling both.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026

Re: Open 7.3 items

From

Tom Lane

Date:

31 July 2002, 18:37:12

Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Yes, we need someone to benchmark both the NAMEDATALEN and FUNC_MAX_ARGS
> to prove we are not causing performance problems.  Once that is done,
> the default limits can be easily increased.  I was thinking 64 for
> NAMEDATALEN and 32 for FUNC_MAX_ARGS, effectively doubling both.

The SQL spec says NAMEDATALEN shall be 128 (or at least 128, too lazy
to look).  If we're gonna change it then I think we should really try
to go to 128.
        regards, tom lane

Re: Open 7.3 items

From

nconway@klamath.dyndns.org (Neil Conway)

Date:

31 July 2002, 18:38:40

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

Re: Open 7.3 items

From

Tom Lane

Date:

31 July 2002, 18:48:09

Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
> Socket permissions - only install user can access db by default
>> 
>> I do not agree with this goal.

> OK, this is TODO item:

> * Make single-user local access permissions the default by limiting
>   permissions on the socket file (Peter E)

Yes, I know what the TODO item says, and I disagree with it.

If we make the default permissions 700, then it's impossible to access
the database unless you run as the database owner.  This is not a
security improvement --- it's more like claiming that a Linux system
would be more secure if you got rid of ordinary users and did all your
work as root.  We should *not* encourage people to operate that way.
(It's certainly unworkable for RPM distributions anyway; only a user
who is hand-building a test installation under his own account would
possibly think that this is a useful default.)

I could see a default setup that made the permissions 770, allowing
access to anyone in the postgres group; that would at least bear some
slight resemblance to a workable production setup.  However, this
assumes that the DBA has root privileges, else he'll not be able to
add/remove users from the postgres group.  Also, on systems where users
all belong to the same "users" group, 770 isn't really better than 777.

The bottom line here is that there isn't any default protection setup
that is really widely useful.  Everyone's got to adjust the thing to
fit their own circumstances.  I'd rather see us spend more documentation
effort on pointing this out and explaining the alternatives, and not
think that we can solve the problem by making the default installation
so tight as to be useless.
        regards, tom lane

Re: Open 7.3 items

From

Rod Taylor

Date:

31 July 2002, 18:54:49

> 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.

Re: Open 7.3 items

From

Tom Lane

Date:

31 July 2002, 19:10:09

>> 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

Re: Open 7.3 items

From

Bruce Momjian

Date:

31 July 2002, 19:43:46

Tom Lane wrote:
> > Point-in-time recovery - ready for 7.3?
> 
> At the moment, it doesn't exist at all.  If patches appear, we can
> review 'em, but right now there is nothing to debate.

Yes, I listed it just to keep it on the radar.

> > Win32 - timefame?
> 
> I've seen nothing to make me think this will be ready for 7.3.

Same.

> > Schema handling - ready? interfaces? client apps?
> 
> The backend will be ready (it's not quite yet).  pg_dump is ready.
> psql is very definitely not ready, nor is pgaccess.  I don't know the
> status for JDBC or ODBC; any comments?  The other interface libraries
> probably don't care.

We should generate a list of subitems here.

> > Dependency - pg_dump auto-create dependencies for 7.2.X data?
> 
> Huh?

Can we create table/sequence dependency linking on loads; same with
other dependencies?  If not, we are going to have trouble with the
dependency code only working some times.  This could be a serious
confusion for users.  We coded some of our stuff assuming the linkage
will always be present, but a load from 7.2 may not have it.  What are
the ramifications?

> > glibc and mktime() - fix?
> 
> We need a fix for this.  Dunno what to do about it.

I have proposed a fix of placing a fixed mktime earlier in the link line
but no one has supplied a fixed mktime for me.

> Other things on my radar screen:
> 
> * I have about zero confidence in the recent tuple-header-size-reduction
> patches.

I have great confidence Manfred Koizar and his work.  I know you want
some checks added to the code and he will do that when he returns.  I
will mention this in the open items list.
improve macros in new tuple header code

> 
> * pg_conversion stuff --- do we understand this thing's behavior under
> failure conditions?  Does it work properly with namespaces and
> dependencies?

Seems Tatsuo says it is OK.

> * pg_dumpall probably ought to dump database privilege settings, also
> per-user and per-database GUC settings.

Added:
have pg_dumpall dump out db privilege and per-user/db settings

> 
> * BeOS and QNX4 ports are busted.

Added:
fix BeOS and QNX4 ports
> * The whole area of which implicit coercions should be allowed is a
> serious problem that we have not spent enough time on.  There are
> a number of cases in which CVS tip is clearly broken compared to
> prior releases.

Oh.   I didn't know that.  Added:
fix implicit type coercions that are worse
> 
> * Bear Giles' SSL patches seem to be causing unhappiness in some
> quarters.

I believe it is only the interfaces/ssl directory I created from his
patch when I didn't know what to do with it.  I wanted to remove it but
someone said it was good stuff and we should give the author until beta
to address it.  Added to TODO:
remove interfaces/ssl if not improved

> 
> * libpqxx is not integrated into build process nor docs.  It should
> be integrated or reversed out before beta.

Added:
integrate or remove new libpqxx

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026

Re: Open 7.3 items

From

Bruce Momjian

Date:

31 July 2002, 19:48:05

If you can contribute it, I think it would be valuable to the two other
Win32 projects that are working on porting the 7.3 code to Win32.

I don't think they will have any code ready for 7.3 but they may have a
few pieces they want to get in to make their 7.3 patching job easier,
like renaming macros or variables or something.


---------------------------------------------------------------------------

Dann Corbit wrote:
> > -----Original Message-----
> > From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> > Sent: Tuesday, July 30, 2002 9:50 PM
> > To: Bruce Momjian
> > Cc: PostgreSQL-development
> > Subject: Re: [HACKERS] Open 7.3 items 
> [snip]
> 
> > > Win32 - timefame?
> 
> I may be able to contribute the Win32 stuff we have done here.  (Not
> sure of it, but they do seem more open to the idea now).  It's only for
> 7.1.3, and so I am not sure how helpful it would be.  There is also a
> bunch of stuff that looks like this in the code:
> 
> #ifdef ICKY_WIN32_KLUDGE
> /* Bletcherous hack to make it work in Win32 goes here... */
> #else
> /* Normal code goes here... */
> #endif
> 
> Let me know if you are interested.
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026

Re: Open 7.3 items

From

Bruce Momjian

Date:

31 July 2002, 19:53:35

Neil Conway wrote:
> On Wed, Jul 31, 2002 at 03:30:30PM -0400, Bruce Momjian wrote:
> > Yes, we need someone to benchmark both the NAMEDATALEN and FUNC_MAX_ARGS
> > to prove we are not causing performance problems.  Once that is done,
> > the default limits can be easily increased.  I was thinking 64 for
> > NAMEDATALEN and 32 for FUNC_MAX_ARGS, effectively doubling both.
> 
> If we're going to change NAMEDATALEN, we should probably set it to 128,
> as that's what SQL99 requires.

OK, updated to show only 128.  Do we need more performance testing?  I
am unclear on that.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026

Re: Open 7.3 items

From

Bruce Momjian

Date:

31 July 2002, 19:54:46

Christopher Kings-Lynne wrote:
> > > Dependency - pg_dump auto-create dependencies for 7.2.X data?
> >
> > Huh?
> 
> Taking a bunch of CREATE CONSTRAINT TRIGGERS and turning them into the
> proper pg_constraint entries...

Description updated:
Dependency - have pg_dump auto-create dependencies when loading7.2.X data?

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026

Re: Open 7.3 items

From

Bruce Momjian

Date:

31 July 2002, 19:57:15

Thomas Lockhart wrote:
> ...
> > I agree that if we could quickly come to a resolution about how this
> > ought to work, there's plenty of time to go off and implement it.  But
> > (1) we failed to come to a consensus before, so I'm not optimistic
> > than one will suddenly emerge now; (2) we've got a ton of other issues
> > that we *need* to deal with before beta.  This one does not strike me
> > as a must-fix, and so I'm loathe to spend much development time on it
> > when there are so many open issues.
> 
> afaict someone else volunteered to do the work. There is no lack of
> consensus that this is a useful feature, at least among those who take
> responsibility to package PostgreSQL for particular platforms. How about
> letting them specify the requirements and if an acceptable solution
> emerges soon, we'll have it for 7.3...

Added to open items:
allow specification of configuration files in a different directory

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026

Re: Open 7.3 items

From

Bruce Momjian

Date:

31 July 2002, 19:58:49

Neil Conway wrote:
> On Tue, Jul 30, 2002 at 11:50:38PM -0400, Bruce Momjian wrote:
> > NAMEDATALEN - disk/performance penalty for increase, 64, 128?
> 
> In my personal testing, I've been unable to observe a significant
> performance impact (as Tom mentioned, I tried getting some profiling
> data with gprof + pgbench, and found that increasing NAMEDATALEN made
> things *faster*). Whether that is enough of an endorsement to make
> the change for 7.3, I'm not sure...

OK, do we need to test further or just bump it to 128?

> > FUNC_MAX_ARGS - disk/performance penalty for increase, 24, 32?
> 
> Until someone takes the time to determine what the performance
> implications of this change will be, I don't think we should
> change this. Given that no one has done any testing, I'm not
> convinced that there's a lot of demand for this anyway.

I am going to list only 32 as an option.  I think it needs to be at
least that high for OpenACS.

> > Point-in-time recovery - ready for 7.3?
> > Reindex/btree shrinkage - does reindex need work, can btree be shrunk?
> 
> I think both of these should probably wait for 7.4

Probably.  We will just keep them on the radar.

> > Schema handling - ready? interfaces? client apps?
> 
> Do we want all client interfaces / admin apps to be aware of schemas in
> time for beta 1, or is the plan to fix these during the beta cycle?

Ideally, before beta or people can't really test them.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026

Re: Open 7.3 items

From

Bruce Momjian

Date:

31 July 2002, 20:05:49

Marc G. Fournier wrote:
> On Wed, 31 Jul 2002, Neil Conway wrote:
> 
> > On Wed, Jul 31, 2002 at 02:01:43AM -0300, Marc G. Fournier wrote:
> > > add in 'fix pg_hba.conf / password issues' to that too :)
> >
> > I doubt that will make 7.3 -- the proposals I've seen on this topic
> > require some reasonably complex additions to the authentication
> > system. We also still need to hash out which design we're going
> > to implement. Given that it's pretty esoteric, I'd prefer this
> > wait for 7.4
> 
> Then, the current changes *should* be removed, as we have no idea how many
> sites out there we are going to break without that functionality ... I
> know I personally have 200+ servers that will all break as soon as I move
> to v7.3 with it as is :(

OK, I have thought about this.  First, a possible solution would be to
have a GUC variable that prepends the dbname to all username
specifications, so the username becomes dbname.username.  When you
CREATE USER "test", it actually does CREATE USER "dbname.test".  Same
with ALTER/DROP user and lookups in pg_hba.conf and authentication. 
Basically it gives us a per-db user namespace.  Only the superuser has a
non-db qualified name.  (Actually, createuser script would fail because
it connects only to template1.  You would have to use psql and CREATE
USER.  Probably other things would fail too.)

As for 7.3, maybe we can get that done in time of everyone likes it.  If
we can't, what do we do?  Do we re-add the secondary password file stuff
that most people don't like?   My big question is how many other
PostgreSQL users figured out they could use the secondary password file
for username/db restrictions?  I never thought of it myself.  Maybe I
should ask on general.

Marc, you do have a workaround for 7.3 using your IP's, right, or is
there a problem with the password having to be the same for different
hosts with the same username?  If Marc is the only one, and he has a
workaround, we may just go ahead and leave it for 7.4.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026

Re: Open 7.3 items

From

Bruce Momjian

Date:

31 July 2002, 20:06:05

Added to open items list:
handle lack of secondary passwords

---------------------------------------------------------------------------

Marc G. Fournier wrote:
> 
> add in 'fix pg_hba.conf / password issues' to that too :)
> 
> On Tue, 30 Jul 2002, Bruce Momjian wrote:
> 
> >
> > Here are the open items for 7.3.  We have one more month to address them
> > before beta.
> >
> > ---------------------------------------------------------------------------
> >
> >                               P O S T G R E S Q L
> >
> >                           7 . 3  O P E N    I T E M S
> >
> >
> > Current at ftp://candle.pha.pa.us/pub/postgresql/open_items.
> >
> > Source Code Changes
> > -------------------
> > Socket permissions - only install user can access db by default
> >     unix_socket_permissions in postgresql.conf
> > NAMEDATALEN - disk/performance penalty for increase, 64, 128?
> > FUNC_MAX_ARGS - disk/performance penalty for increase, 24, 32?
> > Point-in-time recovery - ready for 7.3?
> > Allow easy display of usernames in a group (pg_hba.conf uses groups now)
> > Reindex/btree shrinkage - does reindex need work, can btree be shrunk?
> > DROP COLUMN - ready?
> > CLUSTER - ready?
> > display locks - ready?
> > Win32 - timefame?
> > Prepared statements - ready?
> > Schema handling - ready? interfaces? client apps?
> > Dependency - pg_dump auto-create dependencies for 7.2.X data?
> > glibc and mktime() - fix?
> > Functions Returning Sets - done?
> > ecpg and bison issues - solved?
> >
> >
> > Documentation Changes
> > ---------------------
> >
> >
> > --
> >   Bruce Momjian                        |  http://candle.pha.pa.us
> >   pgman@candle.pha.pa.us               |  (610) 853-3000
> >   +  If your life is a hard drive,     |  830 Blythe Avenue
> >   +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 3: if posting/reading through Usenet, please send an appropriate
> > subscribe-nomail command to majordomo@postgresql.org so that your
> > message can get through to the mailing list cleanly
> >
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026

Re: Open 7.3 items

From

"Iavor Raytchev"

Date:

31 July 2002, 20:12:50

> > psql is very definitely not ready, nor is pgaccess.

I could not really trace who said this.

To my understanding nobody is currently testing how pgaccess is dealing
with 7.3 Am I wrong?

Most problems we try to address now are related to pgaccess working on
most platforms (Brett fights with the dlls, there are some Mac OS X
efforts) and improve the usability (help upon connection failure, etc.)

There are many new features people write, but this has not much to do
with 7.3 in a direct way.

Now in addition to the bugzilla and the developers@pgaccess.org mailing
list, there is also a wiki

http://www.pgaccess.org/wiki/

as a channel for filing ideas and wishes.

Please, feel free to use it.

Iavor

Re: Open 7.3 items

From

Bruce Momjian

Date:

31 July 2002, 20:18:58

Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Tom Lane wrote:
> > Socket permissions - only install user can access db by default
> >> 
> >> I do not agree with this goal.
> 
> > OK, this is TODO item:
> 
> > * Make single-user local access permissions the default by limiting
> >   permissions on the socket file (Peter E)
> 
> Yes, I know what the TODO item says, and I disagree with it.
> 
> If we make the default permissions 700, then it's impossible to access
> the database unless you run as the database owner.  This is not a
> security improvement --- it's more like claiming that a Linux system
> would be more secure if you got rid of ordinary users and did all your
> work as root.  We should *not* encourage people to operate that way.
> (It's certainly unworkable for RPM distributions anyway; only a user
> who is hand-building a test installation under his own account would
> possibly think that this is a useful default.)

I hope they would loosen the default in postgresql.conf rather than
having everyone come in as the same user.  By the time you create new
user accounts, it is trivial to modify postgresql.conf.

> I could see a default setup that made the permissions 770, allowing
> access to anyone in the postgres group; that would at least bear some
> slight resemblance to a workable production setup.  However, this
> assumes that the DBA has root privileges, else he'll not be able to
> add/remove users from the postgres group.  Also, on systems where users
> all belong to the same "users" group, 770 isn't really better than 777.

Yes, groups are nice, but in most cases with a group 'users', it is the
same as world-writable.

> The bottom line here is that there isn't any default protection setup
> that is really widely useful.  Everyone's got to adjust the thing to
> fit their own circumstances.  I'd rather see us spend more documentation
> effort on pointing this out and explaining the alternatives, and not
> think that we can solve the problem by making the default installation
> so tight as to be useless.

I think we are much safer shipping as secure and asking people to loosen
it if they want wider access.  I can imagine a Bugtrack item for
PostgreSQL where they report we ship wide-open for local users.  They
have already reported we don't encrypt our passwords, and we are dealing
with that.  You can say that we tell people to change the default, but
if we install that way, they have a legitimate grip, and PostgreSQL has a
perception problem.

The default unix permissions are world-readable, owner-writable.  We
ship with world-read/write.  I know of _no_ other software that does
that and I can't see how we get away with it.  I will also add that I am
the biggest proponent of tightening things up and on one else seems to
be as concerned about it.  I am not sure why.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026

Re: Open 7.3 items

From

Bruce Momjian

Date:

31 July 2002, 20:22:30

Tom Lane wrote:
> >> Another idea is to change pg_hba.conf to not default to 'trust' but then
> >> the installing user is going to have to choose a password.
> 
> Well, initdb already has an option to request a password.  It would
> perhaps make sense for initdb to alter the installed pg_hba.conf file
> to select local md5 mode instead of local trust mode when this option is
> specified.
> 
> > I like this approach.  Set it to password (or md5) on local, and force
> > the request of a password during initdb.
> 
> I don't like "forcing" people to do anything, especially not things that
> aren't necessarily useful to them.  On a single-user machine there is
> no advantage to using database passwords.

Yes, on a single-user machine, socket permissions are a better approach.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026

Re: Trim the Fat (Was: Re: Open 7.3 items )

From

Bruce Momjian

Date:

31 July 2002, 20:30:21

Andrew Sullivan wrote:
> Actually, the comparison is apt.  There's a reason people suggest
> using your distribution's PHP or Zope or what-have-you packages,
> rather than installing from source: an inexperienced user with these
> packages could easily spend several days trying to figure out all the
> bits to install.  Obviously, such people are new users, and a
> learning curve is expected.  But given recent hand-wringing about the
> relative "mind-share" of Postgres &c., it seems perverse to make a
> new user have to find out (probably by asking on a mailing list) that
> basic stuff like client libraries are a whole separate package, which
> needs to be dealt with separately.  It _would_ be nice, though, to be
> able to get just the client stuff for sure.  And maybe the separation
> is worth it; I just want to be sure that people know the effect on
> users.

I have already provide Marc with a script needed to make an
interfaces-only tarball.  I was about 1/10th the size of the full
tarball.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026

Re: Open 7.3 items

From

Ron Snyder

Date:

31 July 2002, 20:35:14

> As for 7.3, maybe we can get that done in time of everyone 
> likes it.  If
> we can't, what do we do?  Do we re-add the secondary password 
> file stuff
> that most people don't like?   My big question is how many other
> PostgreSQL users figured out they could use the secondary 
> password file
> for username/db restrictions?  I never thought of it myself.  Maybe I
> should ask on general.

Unless I'm misunderstanding you, we use it and like it.  We have several
servers on one machine that all access the same password file (we have it
softlinked).  If we need to create a user that accesses only one cluster,
then they get added to the file and created in the specific cluster.  If
that user then needs access to a different cluster, they just need to be
added to the new cluster.

The reason this is beneficial for us is because we then have the ability to
have postgres only user accounts, as well as accounts from YP.  When the YP
user changes their unix password in YP, their postgres db account password
changes as well (via cronjob).

There are fewer passwords for them to manage in this way, but we still get
the benefit of greater separation between clusters.

Let me know if you want more information about how we use it (or if I
misunderstood).  What is it that people _don't_ like?

-ron

Re: Open 7.3 items

From

Bruce Momjian

Date:

31 July 2002, 20:40:24

Ron Snyder wrote:
> > As for 7.3, maybe we can get that done in time of everyone 
> > likes it.  If
> > we can't, what do we do?  Do we re-add the secondary password 
> > file stuff
> > that most people don't like?   My big question is how many other
> > PostgreSQL users figured out they could use the secondary 
> > password file
> > for username/db restrictions?  I never thought of it myself.  Maybe I
> > should ask on general.
> 
> Unless I'm misunderstanding you, we use it and like it.  We have several
> servers on one machine that all access the same password file (we have it
> softlinked).  If we need to create a user that accesses only one cluster,
> then they get added to the file and created in the specific cluster.  If
> that user then needs access to a different cluster, they just need to be
> added to the new cluster.
> 
> The reason this is beneficial for us is because we then have the ability to
> have postgres only user accounts, as well as accounts from YP.  When the YP
> user changes their unix password in YP, their postgres db account password
> changes as well (via cronjob).
> 
> There are fewer passwords for them to manage in this way, but we still get
> the benefit of greater separation between clusters.
> 
> Let me know if you want more information about how we use it (or if I
> misunderstood).  What is it that people _don't_ like?

OK, how do secondary passwords work in pg_hba.conf.  It requires
clear-text 'password', right, because the password is already crypt-ed
in the file.

Here you are using it for something different, where one file is used
for multiple clusters.  Interesting.

The current code allows you to point to a file for a list of users,
which could be symlinked, so that is handled.  The only part not handled
is the password part.

One idea I had was to look for a colon in the username, and if I see
one, I assume everything after the colon is a password.  Would that work
for you?

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026

Re: Open 7.3 items

From

Peter Eisentraut

Date:

31 July 2002, 21:00:56

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

Re: Open 7.3 items

From

Ron Snyder

Date:

31 July 2002, 21:16:54

> 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

Re: Open 7.3 items

From

Bruce Momjian

Date:

31 July 2002, 21:46:30

Ron Snyder wrote:
> > OK, how do secondary passwords work in pg_hba.conf.  It requires
> > clear-text 'password', right, because the password is already crypt-ed
> > in the file.
> 
> I presume that you're referring to passwords being transmitted clear text?  

Yes, is that your pg_hba.conf line?  'password' is insecure over
networks you don't trust.

> > One idea I had was to look for a colon in the username, and if I see
> > one, I assume everything after the colon is a password.  
> > Would that work
> > for you?
> 
> It would as long as there was an assumption (or method to specify) that the
> stuff after the colon is a crypt()ed password.  Our method to generate the

It would be whatever password is specified on the pg_hba.conf line,
'password', 'crypt', or 'md5'.

> password file is to 'ypcat passwd > /db/etc/password; cat
> /db/etc/pg-only-passwords >> /db/etc/password'.  We could very easily only
> pull only the fields we care about from our yp passwd file.
> 
> I suppose I should also mention that we're not wedded to this method-- we've
> just found it convenient.  If we needed to script something else up to
> connect to the databases and set passwords, we could do that too, it would
> just be a bit more work.

OK.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026

Re: Open 7.3 items

From

Ron Snyder

Date:

31 July 2002, 22:12:23

> 
> Yes, is that your pg_hba.conf line?  'password' is insecure over
> networks you don't trust.

Yes, we're using 'password password' in our pg_hba.conf file.  I trust my
network (so far).

-ron

Re: Open 7.3 items

From

Bruce Momjian

Date:

01 August 2002, 00:11:49

Ron Snyder wrote:
> > 
> > Yes, is that your pg_hba.conf line?  'password' is insecure over
> > networks you don't trust.
> 
> Yes, we're using 'password password' in our pg_hba.conf file.  I trust my
> network (so far).

That is another major limitation to secondary password files.  In fact,
md5 will not even work because we assume the username is used as the
salt for the md5 encryption.  We don't store the salt as part of the
encrypted password like crypt does.  

This was another reason secondary password files were discouraged.

Let me look at adding the colon password capability and see what it
looks like.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026

Re: Trim the Fat (Was: Re: Open 7.3 items )

From

"Christopher Kings-Lynne"

Date:

01 August 2002, 00:36:45

> Mentioning that on -hackers would have been nice -- I've spent a while
> this week hacking autoconf / Makefiles to integrate libpqxx...
>
> The problem I have with removing libpqxx is that libpq++ is a far
> inferior C++ interface. If we leave libpq++ as the only C++ interface
> distributed with PostgreSQL, there will be a tendancy for people
> using PostgreSQL & C++ to use the C++ support included with the
> distribution. Similarly, the Perl interface included with
> PostgreSQL is widely regarded as inferior to DBD::Pg.

I think that if someone is actually working on libpqxx integration - then
yeah, leave it in...

Chris

Re: Open 7.3 items

From

"Marc G. Fournier"

Date:

01 August 2002, 00:46:10

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
:(

Re: Open 7.3 items

From

"Marc G. Fournier"

Date:

01 August 2002, 00:48:59

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 ...

Re: Open 7.3 items

From

"Marc G. Fournier"

Date:

01 August 2002, 00:50:36

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? :)

Re: Open 7.3 items

From

"Christopher Kings-Lynne"

Date:

01 August 2002, 01:06:57

> > 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

Re: Open 7.3 items

From

Bruce Momjian

Date:

01 August 2002, 01:37:43

Marc G. Fournier wrote:
> On Wed, 31 Jul 2002, Bruce Momjian wrote:
> 
> > Ron Snyder wrote:
> > > >
> > > > Yes, is that your pg_hba.conf line?  'password' is insecure over
> > > > networks you don't trust.
> > >
> > > Yes, we're using 'password password' in our pg_hba.conf file.  I trust my
> > > network (so far).
> >
> > That is another major limitation to secondary password files.  In fact,
> > md5 will not even work because we assume the username is used as the
> > salt for the md5 encryption.  We don't store the salt as part of the
> > encrypted password like crypt does.
> >
> > This was another reason secondary password files were discouraged.
> 
> discouraged??  where? :)

Well. I meant that they had very limited usefulness. You had to trust
your network.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026

Re: Open 7.3 items

From

"Marc G. Fournier"

Date:

01 August 2002, 01:44:37

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 ...

Re: Open 7.3 items

From

Bruce Momjian

Date:

01 August 2002, 01:48:51

Marc G. Fournier wrote:
> On Wed, 31 Jul 2002, Bruce Momjian wrote:
> 
> > Marc G. Fournier wrote:
> > > On Wed, 31 Jul 2002, Bruce Momjian wrote:
> > >
> > > > Ron Snyder wrote:
> > > > > >
> > > > > > Yes, is that your pg_hba.conf line?  'password' is insecure over
> > > > > > networks you don't trust.
> > > > >
> > > > > Yes, we're using 'password password' in our pg_hba.conf file.  I trust my
> > > > > network (so far).
> > > >
> > > > That is another major limitation to secondary password files.  In fact,
> > > > md5 will not even work because we assume the username is used as the
> > > > salt for the md5 encryption.  We don't store the salt as part of the
> > > > encrypted password like crypt does.
> > > >
> > > > This was another reason secondary password files were discouraged.
> > >
> > > discouraged??  where? :)
> >
> > Well. I meant that they had very limited usefulness. You had to trust
> > your network.
> 
> that is the case for alot of software, and alot of networks nowadays are
> moving towards encrypted at the switch level, so the local network itself
> is considered to be 'secure' ...
> 
> But, personally, you sooooooo sold me on that GUC thing that if we could
> implement that in time for v7.3, I think alot of ppl would find that
> *quite* valuable ...
> 

I am working on it now.  I decided against doing any kind of database
prepending at the user level.  You create the user as 'dbname.username'.
That is clearer, rather than prepending based on the db you are
connected to.  The only code change is in the postmaster authentication
lookup and ownership setting from the backend connection.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026

Re: Open 7.3 items

From

"Marc G. Fournier"

Date:

01 August 2002, 02:07:59

On Wed, 31 Jul 2002, Bruce Momjian wrote:

> Marc G. Fournier wrote:
> > On Wed, 31 Jul 2002, Bruce Momjian wrote:
> >
> > > Marc G. Fournier wrote:
> > > > On Wed, 31 Jul 2002, Bruce Momjian wrote:
> > > >
> > > > > Ron Snyder wrote:
> > > > > > >
> > > > > > > Yes, is that your pg_hba.conf line?  'password' is insecure over
> > > > > > > networks you don't trust.
> > > > > >
> > > > > > Yes, we're using 'password password' in our pg_hba.conf file.  I trust my
> > > > > > network (so far).
> > > > >
> > > > > That is another major limitation to secondary password files.  In fact,
> > > > > md5 will not even work because we assume the username is used as the
> > > > > salt for the md5 encryption.  We don't store the salt as part of the
> > > > > encrypted password like crypt does.
> > > > >
> > > > > This was another reason secondary password files were discouraged.
> > > >
> > > > discouraged??  where? :)
> > >
> > > Well. I meant that they had very limited usefulness. You had to trust
> > > your network.
> >
> > that is the case for alot of software, and alot of networks nowadays are
> > moving towards encrypted at the switch level, so the local network itself
> > is considered to be 'secure' ...
> >
> > But, personally, you sooooooo sold me on that GUC thing that if we could
> > implement that in time for v7.3, I think alot of ppl would find that
> > *quite* valuable ...
> >
>
> I am working on it now.  I decided against doing any kind of database
> prepending at the user level.  You create the user as 'dbname.username'.
> That is clearer, rather than prepending based on the db you are
> connected to.  The only code change is in the postmaster authentication
> lookup and ownership setting from the backend connection.

Okay, just a couple of questions ... if there any way of provide
'superuse' access a user of the database for creating new users?  Say one
creates a dbname.pgsql account, could it be given 'create user' privileges
for other users with a prefix of dbname.*?

and, what happens if one doesn't specify dbname.*?  does that user become
'global', or have access to nothing?

Re: Open 7.3 items

From

Bruce Momjian

Date:

01 August 2002, 02:18:05

Marc G. Fournier wrote:
> > I am working on it now.  I decided against doing any kind of database
> > prepending at the user level.  You create the user as 'dbname.username'.
> > That is clearer, rather than prepending based on the db you are
> > connected to.  The only code change is in the postmaster authentication
> > lookup and ownership setting from the backend connection.
> 
> Okay, just a couple of questions ... if there any way of provide
> 'superuse' access a user of the database for creating new users?  Say one
> creates a dbname.pgsql account, could it be given 'create user' privileges
> for other users with a prefix of dbname.*?

Uh, that will be tough.

Super-user account will not be qualified by dbname for simplicity.  

> and, what happens if one doesn't specify dbname.*?  does that user become
> 'global', or have access to nothing?

Access to nothing.  I could actually try to quality by dbname.username,
then fall back to just username, but that seems insecure.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026

Re: Open 7.3 items

From

"Marc G. Fournier"

Date:

01 August 2002, 02:27:46

On Wed, 31 Jul 2002, Bruce Momjian wrote:

> Marc G. Fournier wrote:
> > > I am working on it now.  I decided against doing any kind of database
> > > prepending at the user level.  You create the user as 'dbname.username'.
> > > That is clearer, rather than prepending based on the db you are
> > > connected to.  The only code change is in the postmaster authentication
> > > lookup and ownership setting from the backend connection.
> >
> > Okay, just a couple of questions ... if there any way of provide
> > 'superuse' access a user of the database for creating new users?  Say one
> > creates a dbname.pgsql account, could it be given 'create user' privileges
> > for other users with a prefix of dbname.*?
>
> Uh, that will be tough.
>
> Super-user account will not be qualified by dbname for simplicity.
>
> > and, what happens if one doesn't specify dbname.*?  does that user become
> > 'global', or have access to nothing?
>
> Access to nothing.  I could actually try to quality by dbname.username,
> then fall back to just username, but that seems insecure.

No, that's cool ... just questions I thought of ...

Okay ... hmmm ... just making sure that I understand ... I setup a server,
when does this dbname.* come into play?  Only if I enable password/md5 in
pg_hba.conf for a specific database?  all others would still use a plain
'username' still works?  or are you getting rid of the 'global usernames'
altogether (which is cool too, just want to clarify) ...

Re: Open 7.3 items

From

Bruce Momjian

Date:

01 August 2002, 02:31:25

Marc G. Fournier wrote:
> > Access to nothing.  I could actually try to quality by dbname.username,
> > then fall back to just username, but that seems insecure.
> 
> No, that's cool ... just questions I thought of ...

OK.

> Okay ... hmmm ... just making sure that I understand ... I setup a server,
> when does this dbname.* come into play?  Only if I enable password/md5 in
> pg_hba.conf for a specific database?  all others would still use a plain
> 'username' still works?  or are you getting rid of the 'global usernames'
> altogether (which is cool too, just want to clarify) ...

There will be a GUC param db_user_namespace which will turn it on/off
for all access to the cluster _except_ for the super-user.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026

Re: Open 7.3 items

From

nconway@klamath.dyndns.org (Neil Conway)

Date:

01 August 2002, 02:38:30

On Wed, Jul 31, 2002 at 05:05:35PM -0400, Bruce Momjian wrote:
> OK, I have thought about this.  First, a possible solution would be to
> have a GUC variable that prepends the dbname to all username
> specifications, so the username becomes dbname.username.  When you
> CREATE USER "test", it actually does CREATE USER "dbname.test".  Same
> with ALTER/DROP user and lookups in pg_hba.conf and authentication. 
> Basically it gives us a per-db user namespace.  Only the superuser has a
> non-db qualified name.

What about the following situation:
   - 3 databases: 'devel', 'staging', and 'production'
   - one user, 'httpd', which needs access to all 3 databases but     doesn't own any of them
   - I create the 'httpd' user when I'm connected to, say, template1
   - I issue a command that changes the httpd user in some way (e.g.   drops the user, alters the user, etc.) -- what
happens?

Also, what happens if I enable the GUC var, create a bunch of different
users/databases, and then disable it again?

Cheers,

Neil

-- 
Neil Conway <neilconway@rogers.com>
PGP Key ID: DB3C29FC

Re: Open 7.3 items

From

Bruce Momjian

Date:

01 August 2002, 02:40:48

Neil Conway wrote:
> On Wed, Jul 31, 2002 at 05:05:35PM -0400, Bruce Momjian wrote:
> > OK, I have thought about this.  First, a possible solution would be to
> > have a GUC variable that prepends the dbname to all username
> > specifications, so the username becomes dbname.username.  When you
> > CREATE USER "test", it actually does CREATE USER "dbname.test".  Same
> > with ALTER/DROP user and lookups in pg_hba.conf and authentication. 
> > Basically it gives us a per-db user namespace.  Only the superuser has a
> > non-db qualified name.
> 
> What about the following situation:
> 
>     - 3 databases: 'devel', 'staging', and 'production'
> 
>     - one user, 'httpd', which needs access to all 3 databases but
>       doesn't own any of them
> 
>     - I create the 'httpd' user when I'm connected to, say, template1
> 
>     - I issue a command that changes the httpd user in some way (e.g.
>     drops the user, alters the user, etc.) -- what happens?

I am going to require the admin to prepend the dbname.  GUC controls
whether authentication/username map from just the client-supplied
username, or the client username prepended with the dbname.

> 
> Also, what happens if I enable the GUC var, create a bunch of different
> users/databases, and then disable it again?

You swap back and forth between users with prepended dbnames and those
withouth.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026

Re: Open 7.3 items

From

"Marc G. Fournier"

Date:

01 August 2002, 02:58:09

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
;(

Re: Open 7.3 items

From

Bruce Momjian

Date:

01 August 2002, 03:00:03

Marc G. Fournier wrote:
> On Wed, 31 Jul 2002, Bruce Momjian wrote:
> 
> > Marc G. Fournier wrote:
> > > > Access to nothing.  I could actually try to quality by dbname.username,
> > > > then fall back to just username, but that seems insecure.
> > >
> > > No, that's cool ... just questions I thought of ...
> >
> > OK.
> >
> > > Okay ... hmmm ... just making sure that I understand ... I setup a server,
> > > when does this dbname.* come into play?  Only if I enable password/md5 in
> > > pg_hba.conf for a specific database?  all others would still use a plain
> > > 'username' still works?  or are you getting rid of the 'global usernames'
> > > altogether (which is cool too, just want to clarify) ...
> >
> > There will be a GUC param db_user_namespace which will turn it on/off
> > for all access to the cluster _except_ for the super-user.
> 
> Okay ... cluster == database server, or a subset of databases within the
> server?  I know what I think of as a cluster, and somehow I suspect this
> has to do with the new schema stuff, which means I *really* have to find
> time to do some catch-up reading ;)  need more hours in day, days in week

Cluster is db server in this case.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026

Re: Open 7.3 items

From

nconway@klamath.dyndns.org (Neil Conway)

Date:

01 August 2002, 03:06:02

On Wed, Jul 31, 2002 at 11:40:43PM -0400, Bruce Momjian wrote:
> > Also, what happens if I enable the GUC var, create a bunch of different
> > users/databases, and then disable it again?
> 
> You swap back and forth between users with prepended dbnames and those
> withouth.

And if I've created the user before I enabled the GUC var, how does
authentication work?

Cheers,

Neil

-- 
Neil Conway <neilconway@rogers.com>
PGP Key ID: DB3C29FC

Re: Open 7.3 items

From

Bruce Momjian

Date:

01 August 2002, 03:08:05

Neil Conway wrote:
> On Wed, Jul 31, 2002 at 11:40:43PM -0400, Bruce Momjian wrote:
> > > Also, what happens if I enable the GUC var, create a bunch of different
> > > users/databases, and then disable it again?
> > 
> > You swap back and forth between users with prepended dbnames and those
> > withouth.
> 
> And if I've created the user before I enabled the GUC var, how does
> authentication work?

User creation will not be effected.  You have to prepend the dbname
yourself.  This will _now_ only effect modification of the user name as
passed from the client.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026

Re: Open 7.3 items

From

"Marc G. Fournier"

Date:

01 August 2002, 03:08:14

On Wed, 31 Jul 2002, Bruce Momjian wrote:

> Marc G. Fournier wrote:
> > On Wed, 31 Jul 2002, Bruce Momjian wrote:
> >
> > > Marc G. Fournier wrote:
> > > > > Access to nothing.  I could actually try to quality by dbname.username,
> > > > > then fall back to just username, but that seems insecure.
> > > >
> > > > No, that's cool ... just questions I thought of ...
> > >
> > > OK.
> > >
> > > > Okay ... hmmm ... just making sure that I understand ... I setup a server,
> > > > when does this dbname.* come into play?  Only if I enable password/md5 in
> > > > pg_hba.conf for a specific database?  all others would still use a plain
> > > > 'username' still works?  or are you getting rid of the 'global usernames'
> > > > altogether (which is cool too, just want to clarify) ...
> > >
> > > There will be a GUC param db_user_namespace which will turn it on/off
> > > for all access to the cluster _except_ for the super-user.
> >
> > Okay ... cluster == database server, or a subset of databases within the
> > server?  I know what I think of as a cluster, and somehow I suspect this
> > has to do with the new schema stuff, which means I *really* have to find
> > time to do some catch-up reading ;)  need more hours in day, days in week
>
> Cluster is db server in this case.

'K, cool, thanks :)

Okay, final request .. how hard would it be to pre-pend the current
database name if GUC value is on?  ie. if I'm in db1 and run CREATE USER,
it will add db1. to the username if I hadn't already?   Sounds to me it
would be simple to do, and it would "fix" the point I made about being
able to have a db "owner" account with create user privileges (ie. if I'm
in db1 and run CREATE USER db2.bruce, it should reject that unless I've
got create database prileges *and* create user) ...

Other then that, most elegant solution, IMHO :)

Re: Open 7.3 items

From

Bruce Momjian

Date:

01 August 2002, 03:10:00

Marc G. Fournier wrote:
> Okay, final request .. how hard would it be to pre-pend the current
> database name if GUC value is on?  ie. if I'm in db1 and run CREATE USER,
> it will add db1. to the username if I hadn't already?   Sounds to me it
> would be simple to do, and it would "fix" the point I made about being
> able to have a db "owner" account with create user privileges (ie. if I'm
> in db1 and run CREATE USER db2.bruce, it should reject that unless I've
> got create database prileges *and* create user) ...

OK, let me get the easy part working first.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026

Re: Open 7.3 items

From

Bruce Momjian

Date:

01 August 2002, 04:26:11

OK, I have attached a patch for testing.  Sample output is:

    $ sql -U guest test
    psql: FATAL:  user "test.guest" does not exist
    $ createuser test.guest
    Shall the new user be allowed to create databases? (y/n) n
    Shall the new user be allowed to create more new users? (y/n) n
    CREATE USER
    #$ sql -U guest test
    Welcome to psql, the PostgreSQL interactive terminal.

    Type:  \copyright for distribution terms
           \h for help with SQL commands
           \? for help on internal slash commands
           \g or terminate with semicolon to execute query
           \q to quit

    test=>

The patch is quite small.  All it does is prepend the database name to
the user name supplied with the connection request when
db_user_namespace is true.

This is not ready for application.  I can find no way from the
postmaster to determine if the user is the super-user and hence bypass
the database prepending.  I was going to do that _only_ for the username
who created the installation for initdb.  Maybe I have to dump that name
out to a file and read it in from the postmaster.  Other ideas?

It also needs documentation.

I am unsure about auto-prepending the dbname for CREATE USER and other
cases.  That could get confusing, especially because createuser accesses
template1, and we would have to handle all other username mentions, like
in GRANT.  We may be better just leaving it along and telling admins
they have to quality the username in those cases.

---------------------------------------------------------------------------

Marc G. Fournier wrote:
> On Wed, 31 Jul 2002, Bruce Momjian wrote:
>
> > Marc G. Fournier wrote:
> > > On Wed, 31 Jul 2002, Bruce Momjian wrote:
> > >
> > > > Marc G. Fournier wrote:
> > > > > > Access to nothing.  I could actually try to quality by dbname.username,
> > > > > > then fall back to just username, but that seems insecure.
> > > > >
> > > > > No, that's cool ... just questions I thought of ...
> > > >
> > > > OK.
> > > >
> > > > > Okay ... hmmm ... just making sure that I understand ... I setup a server,
> > > > > when does this dbname.* come into play?  Only if I enable password/md5 in
> > > > > pg_hba.conf for a specific database?  all others would still use a plain
> > > > > 'username' still works?  or are you getting rid of the 'global usernames'
> > > > > altogether (which is cool too, just want to clarify) ...
> > > >
> > > > There will be a GUC param db_user_namespace which will turn it on/off
> > > > for all access to the cluster _except_ for the super-user.
> > >
> > > Okay ... cluster == database server, or a subset of databases within the
> > > server?  I know what I think of as a cluster, and somehow I suspect this
> > > has to do with the new schema stuff, which means I *really* have to find
> > > time to do some catch-up reading ;)  need more hours in day, days in week
> >
> > Cluster is db server in this case.
>
> 'K, cool, thanks :)
>
> Okay, final request .. how hard would it be to pre-pend the current
> database name if GUC value is on?  ie. if I'm in db1 and run CREATE USER,
> it will add db1. to the username if I hadn't already?   Sounds to me it
> would be simple to do, and it would "fix" the point I made about being
> able to have a db "owner" account with create user privileges (ie. if I'm
> in db1 and run CREATE USER db2.bruce, it should reject that unless I've
> got create database prileges *and* create user) ...
>
> Other then that, most elegant solution, IMHO :)
>
>

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026
Index: src/backend/libpq/auth.c
===================================================================
RCS file: /cvsroot/pgsql/src/backend/libpq/auth.c,v
retrieving revision 1.82
diff -c -r1.82 auth.c
*** src/backend/libpq/auth.c    20 Jun 2002 20:29:28 -0000    1.82
--- src/backend/libpq/auth.c    1 Aug 2002 05:13:35 -0000
***************
*** 117,123 ****
               version, PG_KRB4_VERSION);
          return STATUS_ERROR;
      }
!     if (strncmp(port->user, auth_data.pname, SM_USER) != 0)
      {
          elog(LOG, "pg_krb4_recvauth: name \"%s\" != \"%s\"",
               port->user, auth_data.pname);
--- 117,123 ----
               version, PG_KRB4_VERSION);
          return STATUS_ERROR;
      }
!     if (strncmp(port->user, auth_data.pname, SM_DATABASE_USER) != 0)
      {
          elog(LOG, "pg_krb4_recvauth: name \"%s\" != \"%s\"",
               port->user, auth_data.pname);
***************
*** 290,296 ****
      }

      kusername = pg_an_to_ln(kusername);
!     if (strncmp(port->user, kusername, SM_USER))
      {
          elog(LOG, "pg_krb5_recvauth: user name \"%s\" != krb5 name \"%s\"",
               port->user, kusername);
--- 290,296 ----
      }

      kusername = pg_an_to_ln(kusername);
!     if (strncmp(port->user, kusername, SM_DATABASE_USER))
      {
          elog(LOG, "pg_krb5_recvauth: user name \"%s\" != krb5 name \"%s\"",
               port->user, kusername);
Index: src/backend/postmaster/postmaster.c
===================================================================
RCS file: /cvsroot/pgsql/src/backend/postmaster/postmaster.c,v
retrieving revision 1.281
diff -c -r1.281 postmaster.c
*** src/backend/postmaster/postmaster.c    13 Jul 2002 01:02:14 -0000    1.281
--- src/backend/postmaster/postmaster.c    1 Aug 2002 05:13:37 -0000
***************
*** 192,197 ****
--- 192,199 ----
  bool        HostnameLookup;        /* for ps display */
  bool        ShowPortNumber;
  bool        Log_connections = false;
+ bool        Db_user_namespace = false;
+

  /* Startup/shutdown state */
  static pid_t StartupPID = 0,
***************
*** 1156,1161 ****
--- 1158,1173 ----
      /* Check a user name was given. */
      if (port->user[0] == '\0')
          elog(FATAL, "no PostgreSQL user name specified in startup packet");
+
+     /* Prefix database name for per-db user namespace */
+     /* XXX look up super-user name from postmaster */
+     if (Db_user_namespace && strcmp(port->user, "postgres"))
+     {
+         char hold_user[SM_DATABASE_USER];
+         snprintf(hold_user, SM_DATABASE_USER, "%s.%s", port->database,
+                  port->user);
+         strcpy(port->user, hold_user);
+     }

      /*
       * If we're going to reject the connection due to database state, say
Index: src/backend/utils/misc/guc.c
===================================================================
RCS file: /cvsroot/pgsql/src/backend/utils/misc/guc.c,v
retrieving revision 1.76
diff -c -r1.76 guc.c
*** src/backend/utils/misc/guc.c    30 Jul 2002 16:20:03 -0000    1.76
--- src/backend/utils/misc/guc.c    1 Aug 2002 05:13:40 -0000
***************
*** 481,486 ****
--- 481,490 ----
          { "transform_null_equals", PGC_USERSET }, &Transform_null_equals,
          false, NULL, NULL
      },
+     {
+         { "db_user_namespace", PGC_SIGHUP }, &Db_user_namespace,
+         false, NULL, NULL
+     },

      {
          { NULL, 0 }, NULL, false, NULL, NULL
Index: src/backend/utils/misc/postgresql.conf.sample
===================================================================
RCS file: /cvsroot/pgsql/src/backend/utils/misc/postgresql.conf.sample,v
retrieving revision 1.42
diff -c -r1.42 postgresql.conf.sample
*** src/backend/utils/misc/postgresql.conf.sample    30 Jul 2002 04:24:54 -0000    1.42
--- src/backend/utils/misc/postgresql.conf.sample    1 Aug 2002 05:13:40 -0000
***************
*** 112,118 ****
  #
  #    Message display
  #
-
  #server_min_messages = notice    # Values, in order of decreasing detail:
                  #   debug5, debug4, debug3, debug2, debug1,
                  #   info, notice, warning, error, log, fatal,
--- 112,117 ----
***************
*** 200,202 ****
--- 199,202 ----
  #sql_inheritance = true
  #transform_null_equals = false
  #statement_timeout = 0                # 0 is disabled
+ #db_user_namespace = false
Index: src/include/libpq/libpq-be.h
===================================================================
RCS file: /cvsroot/pgsql/src/include/libpq/libpq-be.h,v
retrieving revision 1.32
diff -c -r1.32 libpq-be.h
*** src/include/libpq/libpq-be.h    20 Jun 2002 20:29:49 -0000    1.32
--- src/include/libpq/libpq-be.h    1 Aug 2002 05:13:40 -0000
***************
*** 59,65 ****

      ProtocolVersion proto;
      char        database[SM_DATABASE + 1];
!     char        user[SM_USER + 1];
      char        options[SM_OPTIONS + 1];
      char        tty[SM_TTY + 1];
      char        auth_arg[MAX_AUTH_ARG];
--- 59,65 ----

      ProtocolVersion proto;
      char        database[SM_DATABASE + 1];
!     char        user[SM_DATABASE_USER + 1];
      char        options[SM_OPTIONS + 1];
      char        tty[SM_TTY + 1];
      char        auth_arg[MAX_AUTH_ARG];
***************
*** 72,78 ****
      SSL           *ssl;
      X509       *peer;
      char        peer_dn[128 + 1];
!     char        peer_cn[SM_USER + 1];
      unsigned long count;
  #endif
  } Port;
--- 72,78 ----
      SSL           *ssl;
      X509       *peer;
      char        peer_dn[128 + 1];
!     char        peer_cn[SM_DATABASE_USER + 1];
      unsigned long count;
  #endif
  } Port;
Index: src/include/libpq/pqcomm.h
===================================================================
RCS file: /cvsroot/pgsql/src/include/libpq/pqcomm.h,v
retrieving revision 1.64
diff -c -r1.64 pqcomm.h
*** src/include/libpq/pqcomm.h    20 Jun 2002 20:29:49 -0000    1.64
--- src/include/libpq/pqcomm.h    1 Aug 2002 05:13:40 -0000
***************
*** 114,119 ****
--- 114,121 ----
  #define SM_DATABASE        64
  /* SM_USER should be the same size as the others.  bjm 2002-06-02 */
  #define SM_USER            32
+ /* We prepend database name if db_user_namespace true. */
+ #define SM_DATABASE_USER (SM_DATABASE+SM_USER)
  #define SM_OPTIONS        64
  #define SM_UNUSED        64
  #define SM_TTY            64
***************
*** 124,135 ****
--- 126,139 ----
  {
      ProtocolVersion protoVersion;        /* Protocol version */
      char        database[SM_DATABASE];    /* Database name */
+                 /* Db_user_namespace prepends dbname */
      char        user[SM_USER];    /* User name */
      char        options[SM_OPTIONS];    /* Optional additional args */
      char        unused[SM_UNUSED];        /* Unused */
      char        tty[SM_TTY];    /* Tty for debug output */
  } StartupPacket;

+ extern bool Db_user_namespace;

  /* These are the authentication requests sent by the backend. */

Re: Trim the Fat (Was: Re: Open 7.3 items )

From

Thomas Lockhart

Date:

01 August 2002, 04:40:34

> > * 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

Re: Trim the Fat (Was: Re: Open 7.3 items )

From

Tom Lane

Date:

01 August 2002, 04:52:22

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

Re: Trim the Fat (Was: Re: Open 7.3 items )

From

"Marc G. Fournier"

Date:

01 August 2002, 06:15:10

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 ...

Re: Open 7.3 items

From

Hannu Krosing

Date:

01 August 2002, 06:27:01

On Thu, 2002-08-01 at 02:05, Bruce Momjian wrote:
> Marc G. Fournier wrote:
> > On Wed, 31 Jul 2002, Neil Conway wrote:
> > 
> > > On Wed, Jul 31, 2002 at 02:01:43AM -0300, Marc G. Fournier wrote:
> > > > add in 'fix pg_hba.conf / password issues' to that too :)
> > >
> > > I doubt that will make 7.3 -- the proposals I've seen on this topic
> > > require some reasonably complex additions to the authentication
> > > system. We also still need to hash out which design we're going
> > > to implement. Given that it's pretty esoteric, I'd prefer this
> > > wait for 7.4
> > 
> > Then, the current changes *should* be removed, as we have no idea how many
> > sites out there we are going to break without that functionality ... I
> > know I personally have 200+ servers that will all break as soon as I move
> > to v7.3 with it as is :(
> 
> OK, I have thought about this.  First, a possible solution would be to
> have a GUC variable that prepends the dbname to all username
> specifications, so the username becomes dbname.username.

When I first read Marc's post about this I also thought that the users
were partitioned by database, but further reading revealed that tis was
not the case - actually they were partitioned by _a_group_of_databases_,
as each of his virtual hosts accesses on _at_least_ one but possibly
more databases using the same user (bruce ;).

So we would need some sort of database groups that share the same users.

We have to do something like this:
 real_user_name = mk_real_user_name(username,dbname) 

which uses some mapping table to find the real user that is trying to
connect to the database.

This name mangling should be done at connect time and kept out of
database, where each users name should always be fully resolved
(bob@accounting.acme.com). 

This may require raising the length of NAME type to be backwards
compatible. Or we migth just add USEDOMAIN column to uniquely identify
the user. so the above user would still have usename=bob but also
usedomain="accounting.acme.com".

-----------
Hannu

Re: Open 7.3 items

From

Hannu Krosing

Date:

01 August 2002, 06:34:31

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

Re: Open 7.3 items

From

"Dave Page"

Date:

01 August 2002, 06:44:55


> -----Original Message-----
> From: Iavor Raytchev [mailto:iavor.raytchev@verysmall.org]
> Sent: 31 July 2002 22:12
> To: pgsql-hackers
> Cc: pgaccess - developers
> Subject: Re: [HACKERS] Open 7.3 items
>
>
>
> > > psql is very definitely not ready, nor is pgaccess.
>
> I could not really trace who said this.
>
> To my understanding nobody is currently testing how pgaccess
> is dealing with 7.3 Am I wrong?

If my experience with pgAdmin is anything to go on then you've got a
*huge* amount of work to do for 7.3 if you haven't done anything yet.

Regards, Dave.

Re: Open 7.3 items

From

Alvaro Herrera

Date:

01 August 2002, 06:55:50

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)

Re: Open 7.3 items

From

"Zeugswetter Andreas SB SD"

Date:

01 August 2002, 07:22:33

> > > 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

Re: Open 7.3 items

From

Jean-Michel POURE

Date:

01 August 2002, 07:43:37

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?

Re: Trim the Fat (Was: Re: Open 7.3 items )

From

Tom Lane

Date:

01 August 2002, 12:52:43

"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

Re: Trim the Fat (Was: Re: Open 7.3 items )

From

"Marc G. Fournier"

Date:

01 August 2002, 13:05:56

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) ...

Re: Open 7.3 items

From

Tom Lane

Date:

01 August 2002, 13:17:14

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

Re: Open 7.3 items

From

Bruce Momjian

Date:

01 August 2002, 15:34:26

Jean-Michel POURE wrote:
> Le Mercredi 31 Juillet 2002 05:50, Bruce Momjian a ?crit :
> > Here are the open items for 7.3.  We have one more month to address them
> > before beta.
> 
> Is CREATE OR REPLACE VIEW on the list?

No.  It can still be done, but no one is working on it.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026

Re: Open 7.3 items

From

Lamar Owen

Date:

01 August 2002, 15:49:28

On Wednesday 31 July 2002 04:56 pm, Bruce Momjian wrote:
> Thomas Lockhart wrote:
>> Tom Lane wrote:
> > > I agree that if we could quickly come to a resolution about how this
> > > ought to work, there's plenty of time to go off and implement it.

> > afaict someone else volunteered to do the work. There is no lack of
> > consensus that this is a useful feature, at least among those who take
> > responsibility to package PostgreSQL for particular platforms. How about
> > letting them specify the requirements and if an acceptable solution
> > emerges soon, we'll have it for 7.3...

> Added to open items:

>     allow specification of configuration files in a different directory

Thanks Bruce.

I am going to review the previous thread and attempt to distill what can be 
done.  I will then post a summary of what I found, with potential commentary. 
If a consensus is reached, I'd like to see the feature in 7.3.

Peter had mentioned it as well; might want to see if he has done anything as 
yet with it.

That being said, a patch exists for 7.2beta to effect a version of this 
change.  I will also review this patch as I can and see what will be required 
to make this work in CURRENT.

IMO, the key is that if the switch is not specified the current behavior is 
default.  If specified, it will do its thing.
-- 
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Re: Open 7.3 items

From

Bruce Momjian

Date:

01 August 2002, 16:23:37

Tom Lane wrote:
> Hannu Krosing <hannu@tm.ee> writes:
> > This name mangling should be done at connect time and kept out of
> > database, where each users name should always be fully resolved
> > (bob@accounting.acme.com). 
> 
> I really like Hannu's approach to this.  It seems to solve Marc's
> problem with a very simple, easily understood, easily implemented
> feature.  All we need is a postmaster configuration parameter that
> (when TRUE) causes the postmaster to convert the passed username
> into 'username@databasename' before looking it up in pg_shadow.

Yes, that is how the patch I submitted last night does it.

> (Actually, what I'd prefer it do is try first for username, and
> then username@databasename if plain username isn't found.)

Yes, that would be very easy to do _except_ for pg_hba.conf which does a
first-match for username.  We could get into trouble there by trying two
versions of the same name.  Comments?

> With this approach, we have an underlying mechanism that supports
> installation-wide usernames, same as before, but with the flip of
> a switch you can configure the system to support per-database
> usernames.  It's not fancy, maybe, but it will get the job done
> with an appropriate amount of effort.
> 
> We've had several proposals in this thread for complicated extensions
> to the user naming mechanism.  I think that's overdesigning the feature,
> because we have *no* examples of real-world need for such things except
> for Marc's situation.  Let's keep it simple until we see real use cases
> that can drive the design of something fancy.

Agreed.

> 
> > This may require raising the length of NAME type to be backwards
> > compatible.
> 
> Right, but we're planning to do that anyway.

Yes, but that requires a protocol change, which we don't want to do for
7.3.  My fix is to just extend the username on the server side and
append the dbname if the switch is on.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026

Re: Trim the Fat (Was: Re: Open 7.3 items )

From

Bruce Momjian

Date:

01 August 2002, 16:38:27

Marc G. Fournier wrote:
> So, from the 'client side', y'all will still see "everything as one big
> package", while from the 'server side', I'll have the seperate modules
> taht can be packaged independently ...

Marc, how are you dealing with libpq's access to the server include
files?

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026

Re: Open 7.3 items

From

Hannu Krosing

Date:

01 August 2002, 16:44:58

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

Re: Trim the Fat (Was: Re: Open 7.3 items )

From

"Marc G. Fournier"

Date:

01 August 2002, 16:49:46

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 ...

Re: Trim the Fat (Was: Re: Open 7.3 items )

From

Bruce Momjian

Date:

01 August 2002, 17:20:03

Marc G. Fournier wrote:
> On Thu, 1 Aug 2002, Bruce Momjian wrote:
> 
> > Marc G. Fournier wrote:
> > > So, from the 'client side', y'all will still see "everything as one big
> > > package", while from the 'server side', I'll have the seperate modules
> > > taht can be packaged independently ...
> >
> > Marc, how are you dealing with libpq's access to the server include
> > files?
> 
> I haven't touched libpq yet ... I'm talking with the libpqxx guys right
> now concerning getting the standalone libpqxx to work, and will be working
> on figuring out how to get the 'master configure' to make use of the
> standalone configure once that is fixed ... I want to get one module to
> work cleanly before looking at any others ...

But isn't libpq++ just going to be part of interfaces?

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026

Re: Open 7.3 items

From

"Dann Corbit"

Date:

01 August 2002, 17:38:30

I have discussed the idea of contributing our Win32 work to the
PostgreSQL project with management.

We have also converted all of the utilities (initdb, psql, pg_dump,
pg_restore, pg_id, pg_passwd, etc.)

Management is (rightfully) concerned about recouping the many thousands
of dollars invested in the Win32 conversion.

I pointed out that future versions would contain our enhancements and
therefore benefit us directly.

I pointed out that maintenance is 80% of the cost of a software system
and a world-wide team of good programmers would be maintaining the code
for all to benefit.

And last but not least, good computer Kharma.
;-)

They will have to cogitate over it a bit, I think.  If they agree, I
will make a file with our source tree available on an ftp site.

> -----Original Message-----
> From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
> Sent: Wednesday, July 31, 2002 1:48 PM
> To: Dann Corbit
> Cc: Tom Lane; PostgreSQL-development
> Subject: Re: [HACKERS] Open 7.3 items
>
>
>
> If you can contribute it, I think it would be valuable to the
> two other
> Win32 projects that are working on porting the 7.3 code to Win32.
>
> I don't think they will have any code ready for 7.3 but they
> may have a
> few pieces they want to get in to make their 7.3 patching job easier,
> like renaming macros or variables or something.
>
>
> --------------------------------------------------------------
> -------------
>
> Dann Corbit wrote:
> > > -----Original Message-----
> > > From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> > > Sent: Tuesday, July 30, 2002 9:50 PM
> > > To: Bruce Momjian
> > > Cc: PostgreSQL-development
> > > Subject: Re: [HACKERS] Open 7.3 items
> > [snip]
> >
> > > > Win32 - timefame?
> >
> > I may be able to contribute the Win32 stuff we have done here.  (Not
> > sure of it, but they do seem more open to the idea now).
> It's only for
> > 7.1.3, and so I am not sure how helpful it would be.  There
> is also a
> > bunch of stuff that looks like this in the code:
> >
> > #ifdef ICKY_WIN32_KLUDGE
> > /* Bletcherous hack to make it work in Win32 goes here... */
> > #else
> > /* Normal code goes here... */
> > #endif
> >
> > Let me know if you are interested.
> >
> > ---------------------------(end of
> broadcast)---------------------------
> > TIP 3: if posting/reading through Usenet, please send an appropriate
> > subscribe-nomail command to majordomo@postgresql.org so that your
> > message can get through to the mailing list cleanly
> >
>
> --
>   Bruce Momjian                        |  http://candle.pha.pa.us
>   pgman@candle.pha.pa.us               |  (610) 853-3000
>   +  If your life is a hard drive,     |  830 Blythe Avenue
>   +  Christ can be your backup.        |  Drexel Hill,
> Pennsylvania 19026
>

Re: Open 7.3 items

From

"Marc G. Fournier"

Date:

01 August 2002, 17:58:32

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*

Re: Trim the Fat (Was: Re: Open 7.3 items )

From

"Marc G. Fournier"

Date:

01 August 2002, 18:09:28

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
...

Re: Open 7.3 items

From

Tom Lane

Date:

01 August 2002, 19:02:05

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

Re: Open 7.3 items

From

Peter Eisentraut

Date:

01 August 2002, 19:02:31

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

Re: Trim the Fat (Was: Re: Open 7.3 items )

From

Peter Eisentraut

Date:

01 August 2002, 19:03:02

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

Re: Open 7.3 items

From

Peter Eisentraut

Date:

01 August 2002, 19:03:18

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

Re: Open 7.3 items

From

Peter Eisentraut

Date:

01 August 2002, 19:03:28

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

Re: Trim the Fat (Was: Re: Open 7.3 items )

From

Peter Eisentraut

Date:

01 August 2002, 19:33:17

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

Re: Open 7.3 items

From

Lamar Owen

Date:

01 August 2002, 19:49:26

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

Re: Open 7.3 items

From

Bruce Momjian

Date:

01 August 2002, 20:07:47

Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> >> (Actually, what I'd prefer it do is try first for username, and
> >> then username@databasename if plain username isn't found.)
> 
> > Yes, that would be very easy to do _except_ for pg_hba.conf which does a
> > first-match for username.  We could get into trouble there by trying two
> > versions of the same name.  Comments?
> 
> Hm.  I think we'd have to switch around the order of stuff so that we
> look at the flat-file copy of pg_shadow first.  Then we'd know which
> flavor of name we have, and we can proceed with the pg_hba match.
> 
> The reason it's worth doing this is that 'postgres', for example, should
> be an installation-wide username even when you're using db-local names
> for ordinary users.

Yes, that's why my code had a special case for 'postgres' or whatever
super-user name it was installed with.  I think it is cleaner to just
read the install username.  Also, right now, pg_pwd only contains
usernames that have passwords, not all of them.

> > This may require raising the length of NAME type to be backwards
> > compatible.
> >> 
> >> Right, but we're planning to do that anyway.
> 
> > Yes, but that requires a protocol change, which we don't want to do for
> > 7.3.
> 
> What?  We've been discussing raising NAMEDATALEN for months, and no
> one's claimed that it qualifies as a protocol version change.

I thought they were talking about increasing the length of the user NAME
that comes of the wire.  That is currently 32.  I see now he was just
talking about NAMEDATALEN.  Good thing we are prepending the database
name after receiving the name.


--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026

Re: Open 7.3 items

From

Bruce Momjian

Date:

01 August 2002, 20:11:38

Peter Eisentraut wrote:
> Bruce Momjian writes:
> 
> > OK, I have attached a patch for testing.  Sample output is:
> >
> >     $ sql -U guest test
> >     psql: FATAL:  user "test.guest" does not exist
> >     $ createuser test.guest
> 
> I will object to any scheme that makes any characters in the user name
> magic.  Two reasons:  First, do it right, make a separate column.
> Second, several tools use URI syntax to specify data sources.  This will
> break any feature that relies on being able to put special characters into
> the user name.
> 
> The right solution to having database-local user names is putting extra
> information into pg_shadow regarding which database this user applies to.
> It could be an array or some separate "authentication domain" thing.

OK, if you object, you can say goodbye to this feature for 7.3.  I can
supply the patch to Marc and anyone else who wants it but I am not
inclined nor convinced we need that level of work for this feature.

So we end up with nothing.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026

Re: Open 7.3 items

From

Bruce Momjian

Date:

01 August 2002, 20:12:18

Peter Eisentraut wrote:
> Tom Lane writes:
> 
> > We've had several proposals in this thread for complicated extensions
> > to the user naming mechanism.  I think that's overdesigning the feature,
> > because we have *no* examples of real-world need for such things except
> > for Marc's situation.  Let's keep it simple until we see real use cases
> > that can drive the design of something fancy.
> 
> I don't buy this argument.  The reason we have no examples is that people
> are happily using the feature and don't have any reason to tell the world
> about it.

Well, we are going to find out in 7.3 when the secondary password file
is no longer supported.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026

Re: Open 7.3 items

From

"Marc G. Fournier"

Date:

01 August 2002, 20:13:54

On Thu, 1 Aug 2002, Bruce Momjian wrote:

> Peter Eisentraut wrote:
> > Bruce Momjian writes:
> >
> > > OK, I have attached a patch for testing.  Sample output is:
> > >
> > >     $ sql -U guest test
> > >     psql: FATAL:  user "test.guest" does not exist
> > >     $ createuser test.guest
> >
> > I will object to any scheme that makes any characters in the user name
> > magic.  Two reasons:  First, do it right, make a separate column.
> > Second, several tools use URI syntax to specify data sources.  This will
> > break any feature that relies on being able to put special characters into
> > the user name.
> >
> > The right solution to having database-local user names is putting extra
> > information into pg_shadow regarding which database this user applies to.
> > It could be an array or some separate "authentication domain" thing.
>
> OK, if you object, you can say goodbye to this feature for 7.3.  I can
> supply the patch to Marc and anyone else who wants it but I am not
> inclined nor convinced we need that level of work for this feature.
>
> So we end up with nothing.

Stupid qustion .. but why can't you just add a 'domain' column to
pg_passwd/pg_shadow so that its stored as two fields instead of one?
Which I believe is what Pter is/was suggesting ...

Re: Open 7.3 items

From

Bruce Momjian

Date:

01 August 2002, 20:21:03

Marc G. Fournier wrote:
> > > I will object to any scheme that makes any characters in the user name
> > > magic.  Two reasons:  First, do it right, make a separate column.
> > > Second, several tools use URI syntax to specify data sources.  This will
> > > break any feature that relies on being able to put special characters into
> > > the user name.
> > >
> > > The right solution to having database-local user names is putting extra
> > > information into pg_shadow regarding which database this user applies to.
> > > It could be an array or some separate "authentication domain" thing.
> >
> > OK, if you object, you can say goodbye to this feature for 7.3.  I can
> > supply the patch to Marc and anyone else who wants it but I am not
> > inclined nor convinced we need that level of work for this feature.
> >
> > So we end up with nothing.
> 
> Stupid qustion .. but why can't you just add a 'domain' column to
> pg_passwd/pg_shadow so that its stored as two fields instead of one?
> Which I believe is what Pter is/was suggesting ...

Right now, pg_pwd only dumps users with passwords, and as I remember, it
is only accessed when the protocol needs to lookup a password.  It
wasn't designed for anything more advanced.  If you want separate
columns, you have to dump out everyone, and modify CREATE USER,
createuser, ALTER USER, ... to handle those new domain names, and you
have to make this API visible to everyone even if they are not using
domains.  That's where things really get ugly.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026

Re: Open 7.3 items

From

Joe Conway

Date:

01 August 2002, 22:27:50

Bruce Momjian wrote:
> Functions Returning Sets - done?

The basic capability is done, but a number of supporting capabilities 
remain. These are the ones I hope to have done for 7.3:

- PL/pgSQL table function support: not started, but I may get help with  this.
- anonymous composite types: patch submitted
- stand-alone composite types: proposal submitted
- implicit stand-alone composite types on CREATE FUNCTION: proposal  submitted
- Move show_all_settings() from contrib/tablefunc to the backend and  create a system view using the same method as
Neil'spg_locks view.
 

Additional refinements (streaming vs tuplestore, rescan pushed from 
planner to executor, etc) will be 7.4 items.

Additionally on my personal TODO for 7.3 are:
- modify contrib/dblink to take advantage of table function and new  composite type capabilities
- submit string manipulation functions discussed with Thomas a few  weeks ago --> replace(), to_hex(), extract_tok()

Joe

Re: Trim the Fat (Was: Re: Open 7.3 items )

From

jtv

Date:

01 August 2002, 22:45:07

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.)

Re: Trim the Fat (Was: Re: Open 7.3 items )

From

"Marc G. Fournier"

Date:

01 August 2002, 23:07:48

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 ...

Re: Open 7.3 items

From

Hannu Krosing

Date:

02 August 2002, 08:43:51

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

Re: Open 7.3 items

From

Hannu Krosing

Date:

02 August 2002, 08:54:37

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

Re: Open 7.3 items

From

Stephen Deasey

Date:

02 August 2002, 15:47:42

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.

Re: Trim the Fat (Was: Re: Open 7.3 items )

From

"Jeroen T. Vermeulen"

Date:

02 August 2002, 16:53:55

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!)

Re: Open 7.3 items

From

Rod Taylor

Date:

02 August 2002, 17:10:13

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.

Re: Open 7.3 items

From

Peter Eisentraut

Date:

06 August 2002, 20:14:33

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

Re: Open 7.3 items

From

Bruce Momjian

Date:

07 August 2002, 00:09:35

It had such limited usefulness ('password' only, only crypted-hashed
passwords in the file) that it doesn't make much sense to resurect it.

To directly address your point, I don't think this new feature will be
used enough to add the capability to the user admin commands.

I know you object, so I am going to ask for a vote.

OK, here is the request for vote.  Do we want:
1)  the old secondary passwords re-added2)  the new prefixing of the database name to the username when enabled3)  do
nothing

---------------------------------------------------------------------------

Peter Eisentraut wrote:
> Bruce Momjian writes:
> 
> > OK, if you object, you can say goodbye to this feature for 7.3.  I can
> > supply the patch to Marc and anyone else who wants it but I am not
> > inclined nor convinced we need that level of work for this feature.
> 
> The right solution, IMO, is to resurrect the feature we had and think
> about a fully-featured solution for the next release.  Or try to sell the
> proposed solutions as fully-featured . . .
> 
> -- 
> Peter Eisentraut   peter_e@gmx.net
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
> 
> http://www.postgresql.org/users-lounge/docs/faq.html
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026

Re: Open 7.3 items

From

Rod Taylor

Date:

07 August 2002, 00:21:53

> OK, here is the request for vote.  Do we want:

>     2)  the new prefixing of the database name to the username when enabled

I vote 2.

Re: Open 7.3 items

From

"Marc G. Fournier"

Date:

07 August 2002, 00:24:19

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 ...

Re: Open 7.3 items

From

Greg Copeland

Date:

07 August 2002, 00:30:49

I would personally like to see 2, however, Marc is correct IMHO.  I cast
my vote using the qualifiers that Marc laid out below.

Greg


On Tue, 2002-08-06 at 20:24, Marc G. Fournier wrote:
> On Tue, 6 Aug 2002, Bruce Momjian wrote:
>
> >
> > It had such limited usefulness ('password' only, only crypted-hashed
> > passwords in the file) that it doesn't make much sense to resurect it.
>
> It had limited usefulness to you ... but how many sites out there are
> going to break when they try to upgraded without it there?  I do agree
> that it needs to improved / replaced, but without a suitable replacement
> in place, the old should be resurrected until such a suitable one is in
> place ...
>
> > I know you object, so I am going to ask for a vote.
>
> How can you request a vote of such a limited audience?  *Adding*
> functionality is easy ... removing functionality with at least a release
> for-warning is easy ... removing a feature without any forewarning is akin
> to cutting our own throats ...
>
> > OK, here is the request for vote.  Do we want:
> >
> >     1)  the old secondary passwords re-added
> >     2)  the new prefixing of the database name to the username when enabled
> >     3)  do nothing
>
> If 2 can be done in such a way to be transparent, as well as to allow a
> database owner to be able to create users for his/her database, then I
> think it would be great ... and would far exceed what we have now ...
>
> If you can't do 2 as a complete solution, which, IMHO, includes a db owner
> being able to create db.users for his own database, then my vote is for 1
> ... if 2 can be done completely, then I vote for 2, as it would definitely
> be much more useful ...
>
> Hrmmm ... I was just thinking of another scenario where such a feature
> would be great ... educational.  The ability to setup a database server,
> but to give a professor a database for a course that he could create
> 'accounts' for each of the students ...
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster

Re: Open 7.3 items

From

Bruce Momjian

Date:

07 August 2002, 00:50:25

> How can you request a vote of such a limited audience?  *Adding*
> functionality is easy ... removing functionality with at least a release
> for-warning is easy ... removing a feature without any forewarning is akin
> to cutting our own throats ...


Yea, but it was such an ugly feature and I honestly thought no one was
using it.  In fact, you aren't even using it in the indended way of
sharing /etc/passwd.  You are using it to implement a different
capability that I never even imagined.  :-)

> 
> > OK, here is the request for vote.  Do we want:
> >
> >     1)  the old secondary passwords re-added
> >     2)  the new prefixing of the database name to the username when enabled
> >     3)  do nothing
> 
> If 2 can be done in such a way to be transparent, as well as to allow a
> database owner to be able to create users for his/her database, then I
> think it would be great ... and would far exceed what we have now ...
> 
> If you can't do 2 as a complete solution, which, IMHO, includes a db owner
> being able to create db.users for his own database, then my vote is for 1
> ... if 2 can be done completely, then I vote for 2, as it would definitely
> be much more useful ...

Well, as it currently stands in the patch, a db owner can create any
user they want, including users for just their dbs.  However, remember
that Once someone can create a user, they can create a superuser, so
security for those folks is impossible.  The patch does not prevent them
from creating user for other databases, if that is what you wanted, but
did your previous solution allow this?


> 
> Hrmmm ... I was just thinking of another scenario where such a feature
> would be great ... educational.  The ability to setup a database server,
> but to give a professor a database for a course that he could create
> 'accounts' for each of the students ...

Yep, with no conflicting names.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026

Re: Open 7.3 items

From

"Marc G. Fournier"

Date:

07 August 2002, 03:27:09

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 ...

Re: Open 7.3 items

From

Tom Lane

Date:

07 August 2002, 03:43:51

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

Re: Open 7.3 items

From

Joe Conway

Date:

07 August 2002, 03:50:25

Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> 
>>OK, here is the request for vote.  Do we want:
> 
> 
>>    1)  the old secondary passwords re-added
>>    2)  the new prefixing of the database name to the username when enabled
>>    3)  do nothing
> 
> 
> I vote for 2b), username@database ...
> 

I like that too -- and it has the added benefit of being similar to 
Oracle (username@tns_servicename; tns_servicename is really just a 
pointer to the IP/port of a specific Oracle database).

Joe

Re: Open 7.3 items

From

Neil Conway

Date:

07 August 2002, 04:21:33

Bruce Momjian <pgman@candle.pha.pa.us> writes:
> OK, here is the request for vote.  Do we want:
> 
>     1)  the old secondary passwords re-added
>     2)  the new prefixing of the database name to the username when enabled
>     3)  do nothing

I'd vote #3, for the following reasons:
       - The functionality that Marc is worried about (in effect,      allowing multiple database users with the same
name)is      pretty obscure, and the implementation is even more so. I      doubt whether there is *anyone* other than
Marcactually      using it (if that's not the case, please speak up).
 
         Given that it was completely undocumented and a pretty clear         abuse of the existing code, I don't think
it'sunreasonable         for us to break backward compatibility on this issue.
 
       - The old way of doing things is broken, for reasons Bruce has         elaborated on. Unless there's a
compellingreason why we         *need* this feature in the standard distribution, I'd rather         we not go back to
theold way of doing things.
 
       - I'm not perfectly happy with the scheme Bruce suggested as         an interim fix (#2). If we're going to
implementthis         feature, let's do it properly. In particular, I'm not         convinced that this feature is
urgentlyneeded enough to         justify a short-term kludge, and I dislike using a GUC         variable to toggle
betweentwo quite different         authentication processes.
 

So I'd say leave things as they are. One thing I'd like to see anyway
is a more prominent listing of the client-visible incompatibilities in
the release notes -- I'd be content to add an entry to that list for
the 7.3 release and talk about a more elaborate scheme during the 7.4
development cycle.

Cheers,

Neil

-- 
Neil Conway <neilconway@rogers.com>
PGP Key ID: DB3C29FC

Re: Open 7.3 items

From

"Dave Page"

Date:

07 August 2002, 07:02:36


> -----Original Message-----
> From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
> Sent: 07 August 2002 02:09
> To: Peter Eisentraut
> Cc: Marc G. Fournier; Ron Snyder; Neil Conway; PostgreSQL-development
> Subject: Re: [HACKERS] Open 7.3 items
>
>
>
> It had such limited usefulness ('password' only, only
> crypted-hashed passwords in the file) that it doesn't make
> much sense to resurect it.
>
> To directly address your point, I don't think this new
> feature will be used enough to add the capability to the user
> admin commands.
>
> I know you object, so I am going to ask for a vote.
>
> OK, here is the request for vote.  Do we want:
>
>     1)  the old secondary passwords re-added
>     2)  the new prefixing of the database name to the
> username when enabled
>     3)  do nothing

2 please. I have used secondary passwords in the past, but 2 would do
the same job and seems cleaner.

Regards, Dave.

Re: Open 7.3 items

From

Rod Taylor

Date:

07 August 2002, 11:16:03

>         - 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.

Re: Open 7.3 items

From

Neil Conway

Date:

07 August 2002, 12:30:25

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

Re: Open 7.3 items

From

Rod Taylor

Date:

07 August 2002, 12:36:58

> > 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.

Re: Open 7.3 items

From

Tom Lane

Date:

07 August 2002, 13:14:27

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

Re: Open 7.3 items

From

Lamar Owen

Date:

07 August 2002, 13:45:41

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

Re: Open 7.3 items

From

Neil Conway

Date:

07 August 2002, 14:20:57

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

Re: Open 7.3 items

From

Tom Lane

Date:

07 August 2002, 14:29:31

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

Re: Open 7.3 items

From

Bruce Momjian

Date:

07 August 2002, 21:13:24

Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > OK, here is the request for vote.  Do we want:
> 
> >     1)  the old secondary passwords re-added
> >     2)  the new prefixing of the database name to the username when enabled
> >     3)  do nothing
> 
> I vote for 2b), username@database ...

Yes, the format was going to be my second vote, dbname.username or
username@dbname.  Guess I will not need that vote.  ;-)

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026

Re: Open 7.3 items

From

"Marc G. Fournier"

Date:

07 August 2002, 21:27:23

On Wed, 7 Aug 2002, Bruce Momjian wrote:

> Tom Lane wrote:
> > Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > > OK, here is the request for vote.  Do we want:
> >
> > >     1)  the old secondary passwords re-added
> > >     2)  the new prefixing of the database name to the username when enabled
> > >     3)  do nothing
> >
> > I vote for 2b), username@database ...
>
> Yes, the format was going to be my second vote, dbname.username or
> username@dbname.  Guess I will not need that vote.  ;-)

Actually, I kinda like dbname.username myself ... it means that wne you do
a SELECT of the pg_shadow file, it can be sorted in a useful manner (ie.
grouped by database)

Re: Open 7.3 items

From

Hannu Krosing

Date:

07 August 2002, 22:10:32

On Thu, 2002-08-08 at 03:27, Marc G. Fournier wrote:
> On Wed, 7 Aug 2002, Bruce Momjian wrote:
> 
> > Tom Lane wrote:
> > > Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > > > OK, here is the request for vote.  Do we want:
> > >
> > > >     1)  the old secondary passwords re-added
> > > >     2)  the new prefixing of the database name to the username when enabled
> > > >     3)  do nothing
> > >
> > > I vote for 2b), username@database ...
> >
> > Yes, the format was going to be my second vote, dbname.username or
> > username@dbname.  Guess I will not need that vote.  ;-)
> 
> Actually, I kinda like dbname.username myself ... it means that wne you do
> a SELECT of the pg_shadow file, it can be sorted in a useful manner (ie.
> grouped by database)

use a view :

create view pg_shadow_with_domain as   select       usename as fullname,       case when (strpos(usename,'@') > 0)
     then substr(usename,1,strpos(usename,'@')-1)            else usename             end as usename,       case when
(strpos(usename,'@')> 0)            then substr(usename,strpos(usename,'@')+1)            else ''             end as
usedomain,      usesysid,       usecreatedb,       usetrace,       usesuper,       usecatupd,       passwd,
valuntil  from pg_shadow;
 

and sort as you wish ;)

For example, to get all bruces in all domains starting with an 'acc'
just do

select * from pg_shadow_with_domain where usename = 'bruce'  and domain like 'acc%' ;

------------------
Hannu

LRE: Open 7.3 items

From

"Christopher Kings-Lynne"

Date:

08 August 2002, 01:26:36

> 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

Re: Open 7.3 items

From

Tom Lane

Date:

08 August 2002, 01:31:53

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

Re: Open 7.3 items

From

Greg Copeland

Date:

08 August 2002, 01:58:40

Ssshhhh....don't tell Curt that!  ;)

Greg

On Wed, 2002-08-07 at 21:31, Tom Lane wrote:
> Hannu Krosing <hannu@tm.ee> writes:
> > On Thu, 2002-08-08 at 03:27, Marc G. Fournier wrote:
> >> Actually, I kinda like dbname.username myself ... it means that wne you do
> >> a SELECT of the pg_shadow file, it can be sorted in a useful manner (ie.
> >> grouped by database)
>
> Hmm, Marc's got a point there...
>
> > use a view :
>
> Yeah, but it's painful to do that.
>
>             regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster

Re: Open 7.3 items

From

Hannu Krosing

Date:

08 August 2002, 04:29:03

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

Re: Open 7.3 items

From

Tom Lane

Date:

08 August 2002, 04:42:52

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

Re: Open 7.3 items

From

Bruce Momjian

Date:

11 August 2002, 01:42:17

I would like to address this email.  

Lamar is mentioning that it is unfair to remove a feature without
warning.

Let me give a little history.  The secondary password file was created
at a time when we didn't encrypt with random salt over the wire, and we
had people who wanted to share their /etc/passwd file with PostgreSQL.

Later, people wanted to use the secondary password file for just
usernames, so you could list usernames in the file and limit db access
by user.  This is the current usage for 99% of secondary password users.
This capability is better served in 7.3 with the new USER column in
pg_shadow and the ability to specify filenames or groups in that file. 
Keeping the secondary password file to specify a user list while a new
USER column exists in 7.3 is just confusing to administrators.  Our
pg_hba.conf system is pretty complex, so anything we can do to simplify
helps.

Now, on to Marc's case, where he does use the file for usernames _and_
passwords.  However, he is using it only so he can have more than one
person with the same username and restrict access based on the password
in the secondary password file.  While this does work, my submitted
patch makes this much easier and cleaner.

Marc had mentioned that this should be an initdb flag.  However, our
standard procedure is to put stuff in initdb only when it can't be
changed after initdb.  While strange, this feature can be
enabled-disabled after initdb.  A quick update of pg_shadow can change
usernames and you can go in and out of this mode.

Someone talked about pushing this capability into a separate pg_shadow
column, and making CREATE/ALTER user and createuser aware of this. 
While this can be done, and it sort of becomes user schemas, there isn't
enough people wanting this to add complexity to those commands.  A GUC
flag will meet most peoples needs at this point.

Some mentioned using user@dbname, though the idea of sorting made
several recant their votes.

So, based on the voting, I think dbname.username is an agreed-upon
feature addition for 7.3.  I will work on a final patch with
documentation and post it to the patches list for more comment.

---------------------------------------------------------------------------

Lamar Owen wrote:
> On Tuesday 06 August 2002 09:24 pm, Marc G. Fournier wrote:
> > On Tue, 6 Aug 2002, Bruce Momjian wrote:
> > > It had such limited usefulness ('password' only, only crypted-hashed
> > > passwords in the file) that it doesn't make much sense to resurect it.
> 
> > It had limited usefulness to you ... but how many sites out there are
> > going to break when they try to upgraded without it there?  I do agree
> > that it needs to improved / replaced, but without a suitable replacement
> > in place, the old should be resurrected until such a suitable one is in
> > place ...
> 
> While it appears I'll be outvoted on this issue, and even though I agree that 
> the existing functionality is broken, and even though I am not using the 
> functionality, I am reminded of the overall policy that we have historically 
> had about removing even broken features.  Fair Warning must be given. If that 
> policy is going to be changed, then it needs to be applied with equal vigor 
> to all affected cases.
> 
> Even if Marc is the only one using this feature, we should follow established 
> policy -- that is, after all, what policy is for.  To me it seems it is being 
> yanked gratuitously without fair warning.  If every question is answered on a 
> case-by-case basis like this, we will descend to anarchy, I'm afraid.  And, 
> Bruce, I even agree with your reasons -- I just disagree with the method.
> 
> Is it going to cause a major problem for it to remain one release cycle while 
> someone works on a suitable replacement, with the warning in the release 
> notes that while this feature is there for backwards compatibility that it 
> will be yanked at the next release?  And I'm not talking about a minor 
> problem like 'more people will start using it' -- I'm talking 'if it stays we 
> will be in danger of massive data corruption or exposure' -- of course, 
> documenting that there is a degree of exposure of data if not set up in an 
> exacting method, as Marc seems to have done.
> 
> Some may say Marc has fair warning now -- but does anyone know for sure that 
> NO ONE ELSE in the whole world isn't using this feature?  Marc is more in the 
> know than most, granted -- but if he found this use for the feature others 
> may have as well that we don't even know about.
> 
> But if the feature is not going to remain it needs to be prominently 
> documented as being removed in the release notes.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073

Re: Open 7.3 items

From

Michael Meskes

Date:

11 August 2002, 09:36:37

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!

Re: Open 7.3 items

From

Tom Lane

Date:

11 August 2002, 14:12:58

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

Re: Open 7.3 items

From

Lamar Owen

Date:

13 August 2002, 00:29:41

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

Re: Open 7.3 items

From

Karl DeBisschop

Date:

13 August 2002, 00:51:44

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

Re: Open 7.3 items

From

Lamar Owen

Date:

13 August 2002, 01:49:49

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

Re: Open 7.3 items

From

Sean Chittenden

Date:

13 August 2002, 20:25:53

> 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

Re: Open 7.3 items

From

Bruce Momjian

Date:

13 August 2002, 21:22:50

Sean Chittenden wrote:
> > Some mentioned using user@dbname, though the idea of sorting made
> > several recant their votes.
> >
> > So, based on the voting, I think dbname.username is an agreed-upon
> > feature addition for 7.3.  I will work on a final patch with
> > documentation and post it to the patches list for more comment.
> 
> The nice thing about using an @ sign, amongst being more consistent
> with kerberos and email, is that it doesn't preclude the use of .'s in
> a database name.  For simplicity's sake, I'd really like to be able to
> continue issuing database names that are identical to the domain that
> they serve and worry that relying on a "." will either make the use of
> a dot in the username or database impossible.  An @ sign, on the other
> hand, is the ubiquitously agreed upon username/host separator and
> makes it all that much more consistent for users and administrators.
> 
> Username: john.doe
> Database: foo.com
> possible pg_shadow entry #1: john.doe.foo.com
> possible pg_shadow entry #2: john.doe@foo.com
> 
> If people are worried about the sorting, ORDER BY domain, username.
> My $0.02.  -sc

Well, they aren't separate fields so you can't ORDER BY domain.  The dot
was used so it looks like a schema based on dbname.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073

Re: Open 7.3 items

From

Sean Chittenden

Date:

13 August 2002, 23:09:32

> > > Some mentioned using user@dbname, though the idea of sorting made
> > > several recant their votes.
> > >
> > > So, based on the voting, I think dbname.username is an agreed-upon
> > > feature addition for 7.3.  I will work on a final patch with
> > > documentation and post it to the patches list for more comment.
> > 
> > The nice thing about using an @ sign, amongst being more consistent
> > with kerberos and email, is that it doesn't preclude the use of .'s in
> > a database name.  For simplicity's sake, I'd really like to be able to
> > continue issuing database names that are identical to the domain that
> > they serve and worry that relying on a "." will either make the use of
> > a dot in the username or database impossible.  An @ sign, on the other
> > hand, is the ubiquitously agreed upon username/host separator and
> > makes it all that much more consistent for users and administrators.
> > 
> > Username: john.doe
> > Database: foo.com
> > possible pg_shadow entry #1: john.doe.foo.com
> > possible pg_shadow entry #2: john.doe@foo.com
> > 
> > If people are worried about the sorting, ORDER BY domain, username.
> > My $0.02.  -sc
> 
> Well, they aren't separate fields so you can't ORDER BY domain.  The dot
> was used so it looks like a schema based on dbname.

Sorry, I know it's a single field and that there is no split()
function (that I'm aware of), but that seems like such a small and
easy to fix problem that I personally place a higher value on the more
standard nomeclature and use of an @ sign.  I understand the value of
. for schemas and whatnot, but isn't a user going to be in their own
schema to begin with?  As for the order by, I've got a list of users
per "account" (sales account), so doing the order by is on two columns
and the pg_shadow table is generated periodically from our inhouse
tables.  -sc

-- 
Sean Chittenden

Re: Open 7.3 items

From

Bruce Momjian

Date:

14 August 2002, 00:00:13

Sean Chittenden wrote:
> > Well, they aren't separate fields so you can't ORDER BY domain.  The dot
> > was used so it looks like a schema based on dbname.
> 
> Sorry, I know it's a single field and that there is no split()
> function (that I'm aware of), but that seems like such a small and
> easy to fix problem that I personally place a higher value on the more
> standard nomeclature and use of an @ sign.  I understand the value of
> . for schemas and whatnot, but isn't a user going to be in their own
> schema to begin with?  As for the order by, I've got a list of users
> per "account" (sales account), so doing the order by is on two columns
> and the pg_shadow table is generated periodically from our inhouse
> tables.  -sc

I have no personal preference between period and @ or whatever.  See if
you can get some other votes for @ because most left @ when the ORDER BY
idea came up from Marc.

As for it being a special character, it really isn't because the code
prepends the database name and a period.  It doesn't look to see if
there is a period in the already or anything.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073

Re: Open 7.3 items

From

Bruce Momjian

Date:

14 August 2002, 00:37:08

OK, here is the patch to implement db_user_namespace.  It includes
documentation.

I had to add to initdb to create a file /data/PG_INSTALLER and have the
postmaster read that on startup to determine the installing user.

---------------------------------------------------------------------------

Bruce Momjian wrote:
>
> I would like to address this email.
>
> Lamar is mentioning that it is unfair to remove a feature without
> warning.
>
> Let me give a little history.  The secondary password file was created
> at a time when we didn't encrypt with random salt over the wire, and we
> had people who wanted to share their /etc/passwd file with PostgreSQL.
>
> Later, people wanted to use the secondary password file for just
> usernames, so you could list usernames in the file and limit db access
> by user.  This is the current usage for 99% of secondary password users.
> This capability is better served in 7.3 with the new USER column in
> pg_shadow and the ability to specify filenames or groups in that file.
> Keeping the secondary password file to specify a user list while a new
> USER column exists in 7.3 is just confusing to administrators.  Our
> pg_hba.conf system is pretty complex, so anything we can do to simplify
> helps.
>
> Now, on to Marc's case, where he does use the file for usernames _and_
> passwords.  However, he is using it only so he can have more than one
> person with the same username and restrict access based on the password
> in the secondary password file.  While this does work, my submitted
> patch makes this much easier and cleaner.
>
> Marc had mentioned that this should be an initdb flag.  However, our
> standard procedure is to put stuff in initdb only when it can't be
> changed after initdb.  While strange, this feature can be
> enabled-disabled after initdb.  A quick update of pg_shadow can change
> usernames and you can go in and out of this mode.
>
> Someone talked about pushing this capability into a separate pg_shadow
> column, and making CREATE/ALTER user and createuser aware of this.
> While this can be done, and it sort of becomes user schemas, there isn't
> enough people wanting this to add complexity to those commands.  A GUC
> flag will meet most peoples needs at this point.
>
> Some mentioned using user@dbname, though the idea of sorting made
> several recant their votes.
>
> So, based on the voting, I think dbname.username is an agreed-upon
> feature addition for 7.3.  I will work on a final patch with
> documentation and post it to the patches list for more comment.
>

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073
Index: doc/src/sgml/runtime.sgml
===================================================================
RCS file: /cvsroot/pgsql-server/doc/src/sgml/runtime.sgml,v
retrieving revision 1.124
diff -c -r1.124 runtime.sgml
*** doc/src/sgml/runtime.sgml    12 Aug 2002 00:36:11 -0000    1.124
--- doc/src/sgml/runtime.sgml    14 Aug 2002 01:30:15 -0000
***************
*** 1191,1196 ****
--- 1191,1208 ----
       </varlistentry>

       <varlistentry>
+       <term><varname>DB_USER_NAMESPACE</varname> (<type>boolean</type>)</term>
+       <listitem>
+        <para>
+         Prepends the database name and a period to the username when
+         connecting to the database.  This allows per-database users.
+         The user who ran <command>initdb</> is excluded from this
+         handling.
+        </para>
+       </listitem>
+      </varlistentry>
+
+      <varlistentry>
        <indexterm>
         <primary>deadlock</primary>
         <secondary>timeout</secondary>
Index: src/backend/libpq/auth.c
===================================================================
RCS file: /cvsroot/pgsql-server/src/backend/libpq/auth.c,v
retrieving revision 1.82
diff -c -r1.82 auth.c
*** src/backend/libpq/auth.c    20 Jun 2002 20:29:28 -0000    1.82
--- src/backend/libpq/auth.c    14 Aug 2002 01:30:15 -0000
***************
*** 117,123 ****
               version, PG_KRB4_VERSION);
          return STATUS_ERROR;
      }
!     if (strncmp(port->user, auth_data.pname, SM_USER) != 0)
      {
          elog(LOG, "pg_krb4_recvauth: name \"%s\" != \"%s\"",
               port->user, auth_data.pname);
--- 117,123 ----
               version, PG_KRB4_VERSION);
          return STATUS_ERROR;
      }
!     if (strncmp(port->user, auth_data.pname, SM_DATABASE_USER) != 0)
      {
          elog(LOG, "pg_krb4_recvauth: name \"%s\" != \"%s\"",
               port->user, auth_data.pname);
***************
*** 290,296 ****
      }

      kusername = pg_an_to_ln(kusername);
!     if (strncmp(port->user, kusername, SM_USER))
      {
          elog(LOG, "pg_krb5_recvauth: user name \"%s\" != krb5 name \"%s\"",
               port->user, kusername);
--- 290,296 ----
      }

      kusername = pg_an_to_ln(kusername);
!     if (strncmp(port->user, kusername, SM_DATABASE_USER))
      {
          elog(LOG, "pg_krb5_recvauth: user name \"%s\" != krb5 name \"%s\"",
               port->user, kusername);
Index: src/backend/postmaster/postmaster.c
===================================================================
RCS file: /cvsroot/pgsql-server/src/backend/postmaster/postmaster.c,v
retrieving revision 1.283
diff -c -r1.283 postmaster.c
*** src/backend/postmaster/postmaster.c    10 Aug 2002 20:29:18 -0000    1.283
--- src/backend/postmaster/postmaster.c    14 Aug 2002 01:30:17 -0000
***************
*** 116,122 ****
  sigset_t    UnBlockSig,
              BlockSig,
              AuthBlockSig;
-
  #else
  int            UnBlockSig,
              BlockSig,
--- 116,121 ----
***************
*** 191,196 ****
--- 190,197 ----
  bool        HostnameLookup;        /* for ps display */
  bool        ShowPortNumber;
  bool        Log_connections = false;
+ bool        Db_user_namespace = false;
+

  /* Startup/shutdown state */
  static pid_t StartupPID = 0,
***************
*** 208,213 ****
--- 209,216 ----

  bool ClientAuthInProgress = false;    /* T during new-client authentication */

+ static char InstallUser[SM_USER+1];
+
  /*
   * State for assigning random salts and cancel keys.
   * Also, the global MyCancelKey passes the cancel key assigned to a given
***************
*** 258,263 ****
--- 261,267 ----
  static void SignalChildren(int signal);
  static int    CountChildren(void);
  static bool CreateOptsFile(int argc, char *argv[]);
+ static bool GetInstallUser(void);
  static pid_t SSDataBase(int xlop);
         void
  postmaster_error(const char *fmt,...)
***************
*** 690,695 ****
--- 694,702 ----
      if (!CreateOptsFile(argc, argv))
          ExitPostmaster(1);

+     if (!GetInstallUser())
+         ExitPostmaster(1);
+
      /*
       * Set up signal handlers for the postmaster process.
       *
***************
*** 1161,1166 ****
--- 1168,1182 ----
      if (port->user[0] == '\0')
          elog(FATAL, "no PostgreSQL user name specified in startup packet");

+     /* Prefix database name for per-db user namespace */
+     if (Db_user_namespace && strcmp(port->user, InstallUser))
+     {
+         char hold_user[SM_DATABASE_USER];
+         snprintf(hold_user, SM_DATABASE_USER, "%s.%s", port->database,
+                  port->user);
+         strcpy(port->user, hold_user);
+     }
+
      /*
       * If we're going to reject the connection due to database state, say
       * so now instead of wasting cycles on an authentication exchange.
***************
*** 2587,2597 ****
      if (FindExec(fullprogname, argv[0], "postmaster") < 0)
          return false;

!     filename = palloc(strlen(DataDir) + 20);
      sprintf(filename, "%s/postmaster.opts", DataDir);

!     fp = fopen(filename, "w");
!     if (fp == NULL)
      {
          postmaster_error("cannot create file %s: %s",
                           filename, strerror(errno));
--- 2603,2612 ----
      if (FindExec(fullprogname, argv[0], "postmaster") < 0)
          return false;

!     filename = palloc(strlen(DataDir) + 17);
      sprintf(filename, "%s/postmaster.opts", DataDir);

!     if ((fp = fopen(filename, "w")) == NULL)
      {
          postmaster_error("cannot create file %s: %s",
                           filename, strerror(errno));
***************
*** 2614,2619 ****
--- 2629,2669 ----
      return true;
  }

+ /*
+  * Load install user so db_user_namespace can skip it.
+  */
+ static bool
+ GetInstallUser(void)
+ {
+     char       *filename;
+     FILE       *fp;
+
+     filename = palloc(strlen(DataDir) + 14);
+     sprintf(filename, "%s/PG_INSTALLER", DataDir);
+
+     if ((fp = fopen(filename, "r")) == NULL)
+     {
+         postmaster_error("cannot open file %s: %s",
+                          filename, strerror(errno));
+         return false;
+     }
+
+     if (fgets(InstallUser, SM_USER+1, fp) == NULL)
+     {
+         postmaster_error("cannot read file %s: %s",
+                          filename, strerror(errno));
+         return false;
+     }
+
+     /* Trim off trailing newline */
+     if (strchr(InstallUser, '\n') != NULL)
+         *strchr(InstallUser, '\n') = '\0';
+
+     fclose(fp);
+     return true;
+ }
+
+
  /*
   * This should be used only for reporting "interactive" errors (ie, errors
   * during startup.  Once the postmaster is launched, use elog.
Index: src/backend/utils/misc/guc.c
===================================================================
RCS file: /cvsroot/pgsql-server/src/backend/utils/misc/guc.c,v
retrieving revision 1.79
diff -c -r1.79 guc.c
*** src/backend/utils/misc/guc.c    12 Aug 2002 00:36:11 -0000    1.79
--- src/backend/utils/misc/guc.c    14 Aug 2002 01:30:20 -0000
***************
*** 482,487 ****
--- 482,491 ----
          { "transform_null_equals", PGC_USERSET }, &Transform_null_equals,
          false, NULL, NULL
      },
+     {
+         { "db_user_namespace", PGC_SIGHUP }, &Db_user_namespace,
+         false, NULL, NULL
+     },

      {
          { NULL, 0 }, NULL, false, NULL, NULL
Index: src/backend/utils/misc/postgresql.conf.sample
===================================================================
RCS file: /cvsroot/pgsql-server/src/backend/utils/misc/postgresql.conf.sample,v
retrieving revision 1.44
diff -c -r1.44 postgresql.conf.sample
*** src/backend/utils/misc/postgresql.conf.sample    12 Aug 2002 00:36:12 -0000    1.44
--- src/backend/utils/misc/postgresql.conf.sample    14 Aug 2002 01:30:20 -0000
***************
*** 113,119 ****
  #
  #    Message display
  #
-
  #server_min_messages = notice    # Values, in order of decreasing detail:
                  #   debug5, debug4, debug3, debug2, debug1,
                  #   info, notice, warning, error, log, fatal,
--- 113,118 ----
***************
*** 201,203 ****
--- 200,203 ----
  #sql_inheritance = true
  #transform_null_equals = false
  #statement_timeout = 0                # 0 is disabled
+ #db_user_namespace = false
Index: src/bin/initdb/initdb.sh
===================================================================
RCS file: /cvsroot/pgsql-server/src/bin/initdb/initdb.sh,v
retrieving revision 1.165
diff -c -r1.165 initdb.sh
*** src/bin/initdb/initdb.sh    8 Aug 2002 19:39:05 -0000    1.165
--- src/bin/initdb/initdb.sh    14 Aug 2002 01:30:20 -0000
***************
*** 603,608 ****
--- 603,613 ----
  # Top level PG_VERSION is checked by bootstrapper, so make it first
  echo "$short_version" > "$PGDATA/PG_VERSION" || exit_nicely

+ # Top level PG_INSTALLER is used by db_user_namespace to prevent username
+ # mapping just for the install user.
+ echo "$POSTGRES_SUPERUSERNAME" > "$PGDATA/PG_INSTALLER" || exit_nicely
+
+
  cat "$POSTGRES_BKI" \
  | sed -e "s/POSTGRES/$POSTGRES_SUPERUSERNAME/g" \
        -e "s/ENCODING/$MULTIBYTEID/g" \
Index: src/include/libpq/libpq-be.h
===================================================================
RCS file: /cvsroot/pgsql-server/src/include/libpq/libpq-be.h,v
retrieving revision 1.32
diff -c -r1.32 libpq-be.h
*** src/include/libpq/libpq-be.h    20 Jun 2002 20:29:49 -0000    1.32
--- src/include/libpq/libpq-be.h    14 Aug 2002 01:30:20 -0000
***************
*** 59,65 ****

      ProtocolVersion proto;
      char        database[SM_DATABASE + 1];
!     char        user[SM_USER + 1];
      char        options[SM_OPTIONS + 1];
      char        tty[SM_TTY + 1];
      char        auth_arg[MAX_AUTH_ARG];
--- 59,65 ----

      ProtocolVersion proto;
      char        database[SM_DATABASE + 1];
!     char        user[SM_DATABASE_USER + 1];
      char        options[SM_OPTIONS + 1];
      char        tty[SM_TTY + 1];
      char        auth_arg[MAX_AUTH_ARG];
***************
*** 72,78 ****
      SSL           *ssl;
      X509       *peer;
      char        peer_dn[128 + 1];
!     char        peer_cn[SM_USER + 1];
      unsigned long count;
  #endif
  } Port;
--- 72,78 ----
      SSL           *ssl;
      X509       *peer;
      char        peer_dn[128 + 1];
!     char        peer_cn[SM_DATABASE_USER + 1];
      unsigned long count;
  #endif
  } Port;
Index: src/include/libpq/pqcomm.h
===================================================================
RCS file: /cvsroot/pgsql-server/src/include/libpq/pqcomm.h,v
retrieving revision 1.65
diff -c -r1.65 pqcomm.h
*** src/include/libpq/pqcomm.h    12 Aug 2002 14:35:26 -0000    1.65
--- src/include/libpq/pqcomm.h    14 Aug 2002 01:30:20 -0000
***************
*** 114,119 ****
--- 114,121 ----
  #define SM_DATABASE        64
  /* SM_USER should be the same size as the others.  bjm 2002-06-02 */
  #define SM_USER            32
+ /* We prepend database name if db_user_namespace true. */
+ #define SM_DATABASE_USER (SM_DATABASE+SM_USER)
  #define SM_OPTIONS        64
  #define SM_UNUSED        64
  #define SM_TTY            64
***************
*** 124,135 ****
--- 126,139 ----
  {
      ProtocolVersion protoVersion;        /* Protocol version */
      char        database[SM_DATABASE];    /* Database name */
+                 /* Db_user_namespace prepends dbname */
      char        user[SM_USER];    /* User name */
      char        options[SM_OPTIONS];    /* Optional additional args */
      char        unused[SM_UNUSED];        /* Unused */
      char        tty[SM_TTY];    /* Tty for debug output */
  } StartupPacket;

+ extern bool Db_user_namespace;

  /* These are the authentication requests sent by the backend. */

Re: Open 7.3 items

From

Tom Lane

Date:

14 August 2002, 03:11:16

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

Re: Open 7.3 items

From

"Christopher Kings-Lynne"

Date:

14 August 2002, 03:15:27

> 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

Re: Open 7.3 items

From

Hannu Krosing

Date:

14 August 2002, 03:40:55

On Wed, 2002-08-14 at 06:00, Bruce Momjian wrote:
> Sean Chittenden wrote:
> > > Well, they aren't separate fields so you can't ORDER BY domain.  The dot
> > > was used so it looks like a schema based on dbname.

IMHO it should look like an user in domain ;)
> > Sorry, I know it's a single field and that there is no split()
> > function (that I'm aware of), but that seems like such a small and
> > easy to fix problem that I personally place a higher value on the more
> > standard nomeclature and use of an @ sign.  I understand the value of
> > . for schemas and whatnot, but isn't a user going to be in their own
> > schema to begin with?  As for the order by, I've got a list of users
> > per "account" (sales account), so doing the order by is on two columns
> > and the pg_shadow table is generated periodically from our inhouse
> > tables.  -sc
> 
> I have no personal preference between period and @ or whatever.  See if
> you can get some other votes for @ because most left @ when the ORDER BY
> idea came up from Marc.

I still like @ . And I posted code that could be put in the pg_user view
to split out domain you could ORDER BY.
> As for it being a special character, it really isn't because the code
> prepends the database name and a period.  It doesn't look to see if
> there is a period in the already or anything.
-----------
Hannu

Re: Open 7.3 items

From

Bruce Momjian

Date:

14 August 2002, 03:46:02

OK, the vote is not shifting from '.' to '@'.  Is that how we want to
go?  I like the pg_user enhancement.  Marc, comments?  This was your baby.

---------------------------------------------------------------------------

Hannu Krosing wrote:
> On Wed, 2002-08-14 at 06:00, Bruce Momjian wrote:
> > Sean Chittenden wrote:
> > > > Well, they aren't separate fields so you can't ORDER BY domain.  The dot
> > > > was used so it looks like a schema based on dbname.
> 
> IMHO it should look like an user in domain ;)
>  
> > > Sorry, I know it's a single field and that there is no split()
> > > function (that I'm aware of), but that seems like such a small and
> > > easy to fix problem that I personally place a higher value on the more
> > > standard nomeclature and use of an @ sign.  I understand the value of
> > > . for schemas and whatnot, but isn't a user going to be in their own
> > > schema to begin with?  As for the order by, I've got a list of users
> > > per "account" (sales account), so doing the order by is on two columns
> > > and the pg_shadow table is generated periodically from our inhouse
> > > tables.  -sc
> > 
> > I have no personal preference between period and @ or whatever.  See if
> > you can get some other votes for @ because most left @ when the ORDER BY
> > idea came up from Marc.
> 
> I still like @ . And I posted code that could be put in the pg_user view
> to split out domain you could ORDER BY.
>  
> > As for it being a special character, it really isn't because the code
> > prepends the database name and a period.  It doesn't look to see if
> > there is a period in the already or anything.
> -----------
> Hannu
> 
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073

Re: Open 7.3 items

From

Joe Conway

Date:

14 August 2002, 03:46:22

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

Re: Open 7.3 items

From

Sean Chittenden

Date:

14 August 2002, 06:45:58

> > > > 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

Re: Open 7.3 items

From

Hannu Krosing

Date:

14 August 2002, 07:10:08

On Wed, 2002-08-14 at 12:45, Sean Chittenden wrote:
> > > > > Well, they aren't separate fields so you can't ORDER BY domain.  The dot
> > > > > was used so it looks like a schema based on dbname.
> > 
> > IMHO it should look like an user in domain ;)
> 
> Agreed, but there is something to be said for doing a sort of users
> per domain.  This wouldn't be an issue, I don't think, if there was a
> split_before() and split_after() like functions.
> 
> # SELECT split_before('user@domain.com','@'), split_after('user@domain.com', '@');
>  ?column? |  ?column?
> ----------+------------
>  user     | domain.com
> 
> What would you guys say to submissions for a patch that would add the
> function listed above? 

create function split_before(text,text) returns text as 'select case when (strpos($1,$2) > 0)            then
substr($1,1,strpos($1,$2)-1)           else $1             end as usename
 
' language 'SQL';

create function split_after(text,text) returns text as 'select case when (strpos($1,$2) > 0)            then
substr($1,strpos($1,$2)+1)           else ''''             end as usedomain
 
' language 'SQL' ;

hannu=# select split_before('me@somewhere','@'),
split_after('me@somewhere','@');split_before | split_after 
--------------+-------------me           | somewhere
(1 row)

-------------
Hannu

Re: Open 7.3 items

From

Sean Chittenden

Date:

14 August 2002, 08:03:43

> > > > > > Well, they aren't separate fields so you can't ORDER BY domain.  The dot
> > > > > > was used so it looks like a schema based on dbname.
> > > 
> > > IMHO it should look like an user in domain ;)
> > 
> > Agreed, but there is something to be said for doing a sort of users
> > per domain.  This wouldn't be an issue, I don't think, if there was a
> > split_before() and split_after() like functions.
> > 
> > # SELECT split_before('user@domain.com','@'), split_after('user@domain.com', '@');
> >  ?column? |  ?column?
> > ----------+------------
> >  user     | domain.com
> > 
> > What would you guys say to submissions for a patch that would add the
> > function listed above? 
> 
> create function split_before(text,text) returns text as '
>  select case when (strpos($1,$2) > 0)
>              then substr($1,1,strpos($1,$2)-1)
>              else $1
>               end as usename
> ' language 'SQL';
> 
> create function split_after(text,text) returns text as '
>  select case when (strpos($1,$2) > 0)
>              then substr($1,strpos($1,$2)+1)
>              else ''''
>               end as usedomain
> ' language 'SQL' ;
> 
> hannu=# select split_before('me@somewhere','@'),
> split_after('me@somewhere','@');
>  split_before | split_after 
> --------------+-------------
>  me           | somewhere
> (1 row)

Oh that was handy and fast!  I didn't know of strpos().  Cool, who
says 'ya can't learn something every day?  :~) Now with an alias or
subselect, it should be very easy to order users in a domain in any
way that SQL allows.  :~) Thanks Hannu.  -sc

-- 
Sean Chittenden

Re: Open 7.3 items

From

Rod Taylor

Date:

14 August 2002, 11:08:51

I'm going to vote for either @ or %.

On Wed, 2002-08-14 at 00:11, Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > I have no personal preference between period and @ or whatever.  See if
> > you can get some other votes for @ because most left @ when the ORDER BY
> > idea came up from Marc.
> 
> FWIW, I still lean to username@database, so I think we're roughly at a
> tie.  It would be good to get more votes ...

Re: Open 7.3 items

From

ngpg@grymmjack.com

Date:

14 August 2002, 12:47:02

 
> 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?

Re: Open 7.3 items

From

Joe Conway

Date:

14 August 2002, 13:08:59

Sean Chittenden wrote:
> Agreed, but there is something to be said for doing a sort of users
> per domain.  This wouldn't be an issue, I don't think, if there was a
> split_before() and split_after() like functions.
> 
> # SELECT split_before('user@domain.com','@'), split_after('user@domain.com', '@');
>  ?column? |  ?column?
> ----------+------------
>  user     | domain.com
> 
> What would you guys say to submissions for a patch that would add the
> function listed above?  Maybe just a function called get_user(text)
> and get_domain(text)? ::shrug:: Just some thoughts since there is
> validity to being able to parse/operate on this data efficiently.  If
> those functions existed, then I think everyone would be able to have
> their pie as they want it.  -sc
> 

I already have a function in contrib/dblink, currently called 
dblink_strtok(), which I was going to turn into a builtin function per 
recent discussion (renamed of course). It would work for this but is 
more general:

dblink_strtok(text inputstring, text delimiter, int posn) RETURNS text

Inputs  inputstring    any string you want to parse a token out of;    e.g. 'f=1&g=3&h=4'  delimiter    a single
characterto use as the delimiter;    e.g. '&' or '='  posn    the position of the token of interest, 0 based;    e.g.
1

Should it be called splitstr() (similar to substr())?

Joe

Re: Open 7.3 items

From

Andrew Sullivan

Date:

14 August 2002, 13:23:21

On Wed, Aug 14, 2002 at 12:11:10AM -0400, Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > I have no personal preference between period and @ or whatever.  See if
> > you can get some other votes for @ because most left @ when the ORDER BY
> > idea came up from Marc.
> 
> FWIW, I still lean to username@database, so I think we're roughly at a
> tie.  It would be good to get more votes ...

My non-coding vote goes to user@database, too.

A

-- 
----
Andrew Sullivan                               87 Mowat Avenue 
Liberty RMS                           Toronto, Ontario Canada
<andrew@libertyrms.info>                              M6K 3E3                                        +1 416 646 3304
x110

Re: Open 7.3 items

From

Hannu Krosing

Date:

14 August 2002, 13:26:09

On Wed, 2002-08-14 at 16:08, Joe Conway wrote:
> I already have a function in contrib/dblink, currently called 
> dblink_strtok(), which I was going to turn into a builtin function per 
> recent discussion (renamed of course). It would work for this but is 
> more general:
> 
> dblink_strtok(text inputstring, text delimiter, int posn) RETURNS text
> 
> Inputs
>    inputstring
>      any string you want to parse a token out of;
>      e.g. 'f=1&g=3&h=4'
>    delimiter
>      a single character to use as the delimiter;
>      e.g. '&' or '='
>    posn
>      the position of the token of interest, 0 based;
>      e.g. 1
> 
> Should it be called splitstr() (similar to substr())?

What about functions

1. split(text,text,int) returns text

2. split(text,text) returns text[]

and why not

3. split(text,text,text) returns text

which returns text from $1 delimited by $2 and $3

-------------
Hannu

Re: Open 7.3 items

From

Lamar Owen

Date:

14 August 2002, 15:12:26

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

Re: Open 7.3 items

From

Alvaro Herrera

Date:

14 August 2002, 15:25:20

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)

Re: Open 7.3 items

From

Bruce Momjian

Date:

14 August 2002, 16:04:30

We are clearly going for user@db now.

---------------------------------------------------------------------------

Lamar Owen wrote:
> On Tuesday 13 August 2002 07:21 pm, Sander Steffann wrote:
> > I think choosing . as the delimiter is a dangerous choice... People have
> > not expected it to be special until now, so maybe another character can be
> > chosen? I would suggest a colon if possible, so you would get dbname:user.
> > I don't expect that a lot of people use a colon as the dbname or username,
> > but I could be very wrong here.
> 
> The choices have been enumerated as . and @.  I personally vote for either:
> user@db
> OR
> db!user
> (sorry, having been a UUCP node admin shows at times...)  To my eyes the bang 
> notation is more of a 'divider' than the @.  Unless there is some _really_ 
> good reason to not use !, that is. :-)
> -- 
> Lamar Owen
> WGCR Internet Radio
> 1 Peter 4:11
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073

Re: Open 7.3 items

From

Peter Eisentraut

Date:

14 August 2002, 16:13:07

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

Re: Open 7.3 items

From

Bruce Momjian

Date:

14 August 2002, 16:20:17

OK, what I didn't want to do we to over-complexify something that is for
only a few users.  In a way that user has to be special for this case
because of the requirement that at least one person be able to connect
when you flip that flag.

Also, I don't want to add a column to pg_shadow.  Seems like overkill.

Please suggest another name for the file.

Basically, I am not going to stop working on something when one person
objects or this will never get done, and I think we have had enough
feedback on this that people do want this done.

---------------------------------------------------------------------------

Peter Eisentraut wrote:
> Bruce Momjian writes:
> 
> > I had to add to initdb to create a file /data/PG_INSTALLER and have the
> > postmaster read that on startup to determine the installing user.
> 
> I object to treating one user specially.  There should be a general
> mechanism, such as a separate column in pg_shadow.
> 
> I also object to fixing the name during initdb.  We just got rid of that
> requirement.
> 
> If it mattered, I would also object to the choice of the file name.
> 
> -- 
> Peter Eisentraut   peter_e@gmx.net
> 
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073

Re: Open 7.3 items

From

Bruce Momjian

Date:

14 August 2002, 16:35:44

This email brings up another issue I have seen recently.  The use of the
word "object", "strongly object", or "*object*" with stars is a very
confrontational way to express things.  It does not foster discussion;
it really puts your heal in the ground and presents a very unswerving
attitude when it really isn't necessary nor valuable.

It is not just this email, but several people on this list who are doing
that now, and it is making for more negative discussions.  Thomas has
mentioned it too.

As I have said before, everyone gets one vote.  It doesn't matter how
hard to "object" to something. It is the force of your argument that
affects the votes, not how strongly you express your dislike of
something.

One effect of this environment is that you end up coding to avoid
"objections" rather than coding to meet users needs.  Certainly the
people who express objections are providing valuable feedback to help
improve patches/features, but it should be done in a way that doesn't
give the impression they are in a courtroom and when you post something
incorrect, some lawyer is going to jump up and yell "object".

---------------------------------------------------------------------------

Peter Eisentraut wrote:
> Bruce Momjian writes:
> 
> > I had to add to initdb to create a file /data/PG_INSTALLER and have the
> > postmaster read that on startup to determine the installing user.
> 
> I object to treating one user specially.  There should be a general
> mechanism, such as a separate column in pg_shadow.
> 
> I also object to fixing the name during initdb.  We just got rid of that
> requirement.
> 
> If it mattered, I would also object to the choice of the file name.
> 
> -- 
> Peter Eisentraut   peter_e@gmx.net
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073

Re: Open 7.3 items

From

Tom Lane

Date:

14 August 2002, 16:49:06

Bruce Momjian <pgman@candle.pha.pa.us> writes:
> In a way that user has to be special for this case
> because of the requirement that at least one person be able to connect
> when you flip that flag.

Why does anyone need to be special?  The behavior should be to try the
given user name, and if that's not found then to try user@db.  I see no
need to special-case any user.

> Basically, I am not going to stop working on something when one person
> objects or this will never get done,

He didn't say to stop working on it.  He said to fix the misdesigned
parts.  And I quite agree that those parts are misdesigned.
        regards, tom lane

Re: Open 7.3 items

From

Rod Taylor

Date:

14 August 2002, 17:03:25

I believe the dictionary meaning of 'object' in this context would be 'a
cause for concern or attention'.  Each of Peters uses of the word is
highly appropriate, as he was concerned and I'd agree with the
sentiments that those concepts needed attention.

Anyway, object with stars and strongly object are definitely leaning
towards abuse of the word.

On Wed, 2002-08-14 at 13:35, Bruce Momjian wrote:
> 
> This email brings up another issue I have seen recently.  The use of the
> word "object", "strongly object", or "*object*" with stars is a very

> > > I had to add to initdb to create a file /data/PG_INSTALLER and have the
> > > postmaster read that on startup to determine the installing user.
> > 
> > I object to treating one user specially.  There should be a general
> > mechanism, such as a separate column in pg_shadow.
> > 
> > I also object to fixing the name during initdb.  We just got rid of that
> > requirement.
> > 
> > If it mattered, I would also object to the choice of the file name.

Re: Open 7.3 items

From

Bruce Momjian

Date:

14 August 2002, 17:25:15

Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > In a way that user has to be special for this case
> > because of the requirement that at least one person be able to connect
> > when you flip that flag.
> 
> Why does anyone need to be special?  The behavior should be to try the
> given user name, and if that's not found then to try user@db.  I see no
> need to special-case any user.

Oh, so try it with and without.  I can do that, but it seems more of a
security problem where you were trying two names instead of one.  Do
people like that?  It is easy to do, except for the fact we have to
match pg_hba.conf with a username, though we could do the double-test
there too, if that isn't too weird.

> > Basically, I am not going to stop working on something when one person
> > objects or this will never get done,
> 
> He didn't say to stop working on it.  He said to fix the misdesigned
> parts.  And I quite agree that those parts are misdesigned.

I will fix them as long as the fixes don't generate new objections, like
adding a new column to pg_shadow.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073

Re: Open 7.3 items

From

Tom Lane

Date:

14 August 2002, 17:35:29

Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Oh, so try it with and without.  I can do that, but it seems more of a
> security problem where you were trying two names instead of one.  Do
> people like that?

The nice thing about it is you can have any combination of people with
installation-wide access (create them as joeblow) and people with
one-database access (create them as joeblow@joesdatabase).  A special
case for only the postgres user is much less flexible.

> It is easy to do, except for the fact we have to
> match pg_hba.conf with a username, though we could do the double-test
> there too, if that isn't too weird.

It'd probably be better to first look at the flat-file copy of pg_shadow
to determine whether user or user@database is the form to use, and then
run through pg_hba.conf only once using the correct form.  Otherwise
there are going to be all sorts of weird corner cases: user might match
a different pg_hba row than user@database does.

Also, if you do it this way then the substitution only has to be done in
one place: you can pass down the correct form to the backend, which'd
otherwise have to repeat the test to see which username is found.
        regards, tom lane

Re: Open 7.3 items

From

Bruce Momjian

Date:

14 August 2002, 17:38:25

Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Oh, so try it with and without.  I can do that, but it seems more of a
> > security problem where you were trying two names instead of one.  Do
> > people like that?
> 
> The nice thing about it is you can have any combination of people with
> installation-wide access (create them as joeblow) and people with
> one-database access (create them as joeblow@joesdatabase).  A special
> case for only the postgres user is much less flexible.

Oh, yes, clearly a nice addition, but see below.

> > It is easy to do, except for the fact we have to
> > match pg_hba.conf with a username, though we could do the double-test
> > there too, if that isn't too weird.
> 
> It'd probably be better to first look at the flat-file copy of pg_shadow
> to determine whether user or user@database is the form to use, and then
> run through pg_hba.conf only once using the correct form.  Otherwise
> there are going to be all sorts of weird corner cases: user might match
> a different pg_hba row than user@database does.

Problem is that pg_shadow flat file _only_ has users with passwords.  I
do a btree search of that file, but I am not sure I want to add a dump
of _all_ users just to allow this.  Do we?

> Also, if you do it this way then the substitution only has to be done in
> one place: you can pass down the correct form to the backend, which'd
> otherwise have to repeat the test to see which username is found.

Yes, certainly a big win.  What we _could_ do is to allow connections to
template1 be unsuffixed by the dbname, but that makes everyone
connecting to template1 have problems, and just seemed too weird.

Ideas?

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073

Re: Open 7.3 items

From

Rod Taylor

Date:

14 August 2002, 17:40:39

On Wed, 2002-08-14 at 14:34, Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Oh, so try it with and without.  I can do that, but it seems more of a
> > security problem where you were trying two names instead of one.  Do
> > people like that?
> 
> The nice thing about it is you can have any combination of people with
> installation-wide access (create them as joeblow) and people with
> one-database access (create them as joeblow@joesdatabase).  A special
> case for only the postgres user is much less flexible.
> 
> > It is easy to do, except for the fact we have to
> > match pg_hba.conf with a username, though we could do the double-test
> > there too, if that isn't too weird.
> 
> It'd probably be better to first look at the flat-file copy of pg_shadow
> to determine whether user or user@database is the form to use, and then
> run through pg_hba.conf only once using the correct form.  Otherwise
> there are going to be all sorts of weird corner cases: user might match
> a different pg_hba row than user@database does.
> 
> Also, if you do it this way then the substitution only has to be done in
> one place: you can pass down the correct form to the backend, which'd
> otherwise have to repeat the test to see which username is found.

If there is a global 'user', then a database specific 'user@database'
should be rejected shouldn't it?  Otherwise we wind up with two
potential 'user@database' users (globals users are really user@<each
database>) but with a single ID.

Re: Open 7.3 items

From

Lamar Owen

Date:

14 August 2002, 17:51:54

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

Re: Open 7.3 items

From

Tom Lane

Date:

14 August 2002, 18:04:46

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

Re: Open 7.3 items

From

Tom Lane

Date:

14 August 2002, 18:05:50

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

Re: Open 7.3 items

From

Vince Vielhaber

Date:

14 August 2002, 18:29:43

On Wed, 14 Aug 2002, Tom Lane wrote:

> Lamar Owen <lamar.owen@wgcr.org> writes:
> > Appending '@template1' to unadorned usernames, and giving inherited rights
> > across the installation to users with template1 rights?  Then you have the
> > unadorned 'lowen' becomes 'lowen@template1' -- but lowen@pari wouldn't have
> > access to template1, right?
>
> If not, standard things like "psql -l" won't work for lowen@pari.  I don't
> think we can get away with a scheme that depends on disallowing access
> to template1 for most people.
>
> It should also be noted that the whole point of this little project was
> to do something *simple* ... checking access to some other database to
> decide what we will allow is getting a bit far afield from simple.

Hate to complicate things more, but back to a global username, say
you have user "lowen" that should have access to all databases.  What
happens if there's already a lowen@somedb that's an unprivileged user.
Assuming lowen is a db superuser, what happens in somedb?  If there's
a global user "lowen" and you try to create a lowen@somedb later, will
it be allowed?

One possible simplification would be to make the username the full
username "lowen@somedb", "lowen", ...  Right now we can create a
"lowen@somedb" and it's a different user than "lowen" and we can
already restrict a user to one database, can't we?  Hmmm.  Just
checked and I guess not - I thought we had a record type of "user".

Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH    email: vev@michvhf.com    http://www.pop4.net        56K Nationwide Dialup from $16.00/mo
atPop4 Networking     http://www.camping-usa.com      http://www.cloudninegifts.com  http://www.meanstreamradio.com
 http://www.unknown-artists.com

==========================================================================

Re: Open 7.3 items

From

Lamar Owen

Date:

14 August 2002, 18:31:23

On Wednesday 14 August 2002 03:04 pm, Tom Lane wrote:
> Lamar Owen <lamar.owen@wgcr.org> writes:
> > Appending '@template1' to unadorned usernames, and giving inherited
> > rights across the installation to users with template1 rights?  Then you
> > have the unadorned 'lowen' becomes 'lowen@template1' -- but lowen@pari
> > wouldn't have access to template1, right?

> If not, standard things like "psql -l" won't work for lowen@pari.  I don't
> think we can get away with a scheme that depends on disallowing access
> to template1 for most people.

Ok, maybe I'm really off base, but if I connect to database pari as 
lowen@pari, isn't pg_database present there?  I just tried here:
createdb pari
psql pari
Welcome to psql, the PostgreSQL interactive terminal.

Type:  \copyright for distribution terms      \h for help with SQL commands      \? for help on internal slash commands
    \g or terminate with semicolon to execute query      \q to quit

pari=# select datname from pg_database; datname
------------acs-testmaillabelstesting2template1template0pari
(6 rows)

So AFAICT if I were psql I would parse the unadorned lowen as 
'lowen@template1' and connect to template1 if not otherwise specified.  If 
the fully qualified database user (FQDU) is present, parse the database name 
out and connect to that database, then issue the SQL to do the -l or 
whatever.  The @pari would just override the normal default of template1, 
right?  So a 'psql -U lowen@pari -l '  would connect to database pari 
(subject to permissions) and select datname from pg_database there.

What else am I missing, Tom?  ISTM I don't need access to template1 -- 
although I wasn't necessarily suggesting eliminating that.  I was more 
suggesting:
lowen@pari has read access to those parts of template1 necessary for normal 
functioning, full access (subject ot GRANT/REVOKE) of pari, and no access to 
other databases;
lowen@template1 has access across the install (subject to GRANT/REVOKE, of 
course). lowen@template1 = lowen (unadorned).  That was the answer, I 
thought, to the question Bruce had.  There would be NO unadorned usernames 
then, and no special handling EXCEPT of the template1 database, which is 
already a special case.

Now, can we support the idea of 'postgres@pari' being a superuser for pari but 
not for the rest of the install?  Meaning no CREATE DATABASE right, as that 
would require write access to template1?  That's OK I believe, as I would 
assume a 'tied to a database' superuser shouldn't be allowed to create a new 
database to which he isn't going to have access..... The full ramifications 
of this structure could prove interesting.

The supersuperuser 'postgres' becomes postgres@template1 -- template1 becoming 
the consistent default database (for connecting as well as user membership).  
As anything added to template1 becomes part of any subsequently added 
databases, being a user in template1 becomes an installation-wide user.

And the user never really has to explicitly state @template1 -- they could 
just leave off the @template1 and everything works as it does now.

Yes, there are complications, but not great ones, no?
-- 
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Re: Open 7.3 items

From

Bruce Momjian

Date:

14 August 2002, 18:32:37

Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Problem is that pg_shadow flat file _only_ has users with passwords.  I
> > do a btree search of that file, but I am not sure I want to add a dump
> > of _all_ users just to allow this.  Do we?
> 
> Why not?  Doesn't seem like a big penalty ...

Well, in most cases pg_pwd doesn't even get created unless someone has a
password.  We would be creating that file in all cases, or at least in
all cases wher db_user_namespace is set, and again, that is a SIGHUP
param, so you would need to make sure pg_pwd has the right contents if
it was enabled during a sighup.  Frankly, I would recommend a new file
that just contains user names and is always created.

We are basically heading down the road to complexity here.

In fact, pg_hba.conf is just a microcosm of how we are going to handle
pg_shadow matching.  If we create dave@db1, then when dave tries to
connect to db1, he comes in as dave@db1, but when he goes to connect to
db2, if there is a plain 'dave', he will connect as 'dave' to db2, if
possible.

If people are OK with that, then I can easily push the double-testing
down into the authentication system.  It merely means testing the new
pg_hba.conf USER column for two values, and pg_shadow for two values,
but I would test with @db first.

The double testing just seems strange to me because it splits the user
namespace into two parts one with @ and one without, and conflicting
user parts in the two namespaces do interact when @db does not match. 
That seems strange, but hey, if no one else thinks it is strange, it is
easy to code.  It is basically the same as testing pg_pwd, just doing it
later in the code.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073

Re: Open 7.3 items

From

Lamar Owen

Date:

14 August 2002, 18:36:05

On Wednesday 14 August 2002 03:29 pm, Vince Vielhaber wrote:
> Hate to complicate things more, but back to a global username, say
> you have user "lowen" that should have access to all databases.  What
> happens if there's already a lowen@somedb that's an unprivileged user.
> Assuming lowen is a db superuser, what happens in somedb?  If there's
> a global user "lowen" and you try to create a lowen@somedb later, will
> it be allowed?

If the user 'lowen' is then expanded to 'lowen@template1' it would be stored 
that way -- and lowen@template1 is different from lowen@pari, for instance.  
The lowen@template1 user could be a superuser and lowen@pari might not -- but 
they become distinct users.  Although I do understand the difficulty if the 
FQDU isn't stored in full in the appropriate places.  So I guess the solution 
is that wherever a user name is to be stored, the fully qualified form must 
be used and checked against, with @template1 being a 'this user is 
everywhere' shorthand.

But maybe I'm just misunderstanding the implementation.
-- 
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Re: Open 7.3 items

From

Bruce Momjian

Date:

14 August 2002, 18:49:30

Lamar Owen wrote:
> On Wednesday 14 August 2002 03:29 pm, Vince Vielhaber wrote:
> > Hate to complicate things more, but back to a global username, say
> > you have user "lowen" that should have access to all databases.  What
> > happens if there's already a lowen@somedb that's an unprivileged user.
> > Assuming lowen is a db superuser, what happens in somedb?  If there's
> > a global user "lowen" and you try to create a lowen@somedb later, will
> > it be allowed?
> 
> If the user 'lowen' is then expanded to 'lowen@template1' it would be stored 
> that way -- and lowen@template1 is different from lowen@pari, for instance.  
> The lowen@template1 user could be a superuser and lowen@pari might not -- but 
> they become distinct users.  Although I do understand the difficulty if the 
> FQDU isn't stored in full in the appropriate places.  So I guess the solution 
> is that wherever a user name is to be stored, the fully qualified form must 
> be used and checked against, with @template1 being a 'this user is 
> everywhere' shorthand.

Yes, Vince is on to something with his quote above.

If we have users with and without @, we get into the situation where
users without @ may become users with @ when their usernames collide
with existing user/db combinations already created.  The point is that
those two namespaces do collide and will cause confusion.

Then you start to get into the situation where you always add @ and make
@template1 a special case.  However, remember that this flag can be
turned on and off after initdb, so you need to be able to get in to set
things up without great complexity _and_ the @template1 would not be
passed in from the client, if for no other reason that the username is
only 32 characters. It is the backend doing the flagging, and therefore
the user can't say 'I am dave@templatge1' vs 'I am dave@connectdb'.

This is how I got to the installuser hack in the first place.  In fact,
even the install user, typically 'postgres' has a problem because if you
create 'postgres@db1', 'postgres' will have trouble connecing to db1 as
themselves. I think we can live with one user who is special/global, but
not more than one because of the confusion it would create.

I can change the way this works, but we need a solution without holes.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073

Re: Open 7.3 items

From

Vince Vielhaber

Date:

14 August 2002, 18:55:20

On Wed, 14 Aug 2002, Lamar Owen wrote:

> On Wednesday 14 August 2002 03:29 pm, Vince Vielhaber wrote:
> > Hate to complicate things more, but back to a global username, say
> > you have user "lowen" that should have access to all databases.  What
> > happens if there's already a lowen@somedb that's an unprivileged user.
> > Assuming lowen is a db superuser, what happens in somedb?  If there's
> > a global user "lowen" and you try to create a lowen@somedb later, will
> > it be allowed?
>
> If the user 'lowen' is then expanded to 'lowen@template1' it would be stored
> that way -- and lowen@template1 is different from lowen@pari, for instance.
> The lowen@template1 user could be a superuser and lowen@pari might not -- but
> they become distinct users.  Although I do understand the difficulty if the
> FQDU isn't stored in full in the appropriate places.  So I guess the solution
> is that wherever a user name is to be stored, the fully qualified form must
> be used and checked against, with @template1 being a 'this user is
> everywhere' shorthand.
>
> But maybe I'm just misunderstanding the implementation.

I may be too, but what's wrong with just "lowen" being shorthand for
'this user is everywhere'?  Does it also mean that we'd have a user
postgres@template1?

Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH    email: vev@michvhf.com    http://www.pop4.net        56K Nationwide Dialup from $16.00/mo
atPop4 Networking     http://www.camping-usa.com      http://www.cloudninegifts.com  http://www.meanstreamradio.com
 http://www.unknown-artists.com
 
==========================================================================

Re: Open 7.3 items

From

Lamar Owen

Date:

14 August 2002, 19:34:21

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

Re: Open 7.3 items

From

Lamar Owen

Date:

14 August 2002, 20:01:15

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

Re: Open 7.3 items

From

Tom Lane

Date:

14 August 2002, 20:44:30

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

Re: Open 7.3 items

From

Peter Eisentraut

Date:

14 August 2002, 20:59:57

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

Re: Open 7.3 items

From

Bruce Momjian

Date:

14 August 2002, 21:28:37

OK, I have a new idea.  Seems most don't like that 'postgres' is a
special user in this context.

How about if we just document that they have to create a
postgres@template1 user before flipping the switch.  That way, there is
no special user, no PG_INSTALLER file, and no double-tests for user
names.

It doesn't give us a global user, but frankly, it seems that such a
system is never going to work reliably.

Trying to prevent namespace conflicts by checking for users without @
that may match will make @ a special character in the user namespace,
and people won't like that.

---------------------------------------------------------------------------

Tom Lane wrote:
> Lamar Owen <lamar.owen@wgcr.org> writes:
> > So the former plain 'postgres' user could still be such to us, to client 
> > programs, etc, but the backend would assume that that meant 
> > postgres@template1 -- no namespace collision, and the special case is that 
> > anyone@template1 has the behavior the unadorned plain user now has.
> 
> The trouble with that scheme is that there is zero interoperability
> between the plain-vanilla mode (postgres is postgres in pg_shadow) and
> the @-mode (postgres is postgres@template1 in pg_shadow).  Flip the
> configuration switch, in either direction, and you can't log in anymore.
> We'd almost have to make it a frozen-at-initdb setting so that initdb
> would know which form to put into pg_shadow for the superuser, and so
> that entry wouldn't break thereafter.
> 
> The reason I like the "lowen" vs "lowen@somedb" pattern is that
> database-global users can log in the same way whether the feature is
> turned on or not; this eliminates the getting-started problem, as well
> as the likelihood of shooting yourself in the foot.
> 
> It is true that if you have a global user lowen you'd want to avoid
> creating any local users lowen@somedb, and that the existing code
> wouldn't be able to enforce that.  We could possibly add a few lines
> to CREATE USER to warn about this mistake.  (It should be a warning not
> an error, since if you have no intention of ever using the @-feature
> then there's no reason to restrict your choice of usernames.)
> 
>             regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073

Re: Open 7.3 items

From

Tom Lane

Date:

14 August 2002, 21:56:29

Bruce Momjian <pgman@candle.pha.pa.us> writes:
> How about if we just document that they have to create a
> postgres@template1 user before flipping the switch.  That way, there is
> no special user, no PG_INSTALLER file, and no double-tests for user
> names.

... and no useful superuser account; if you can't connect to anything
except template1 then you ain't much of a superuser.

To get around that you'd have to create postgres@db1, postgres@db2,
postgres@db3, etc etc.  This would be a huge pain in the neck; I think
it'd render the scheme impractical.  (Keep in mind that anybody who'd be
interested in this feature at all has probably got quite a number of
databases to contend with.)
        regards, tom lane

Re: Open 7.3 items

From

"Nigel J. Andrews"

Date:

14 August 2002, 22:30:05

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

Re: Open 7.3 items

From

Bruce Momjian

Date:

14 August 2002, 22:44:33

Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > How about if we just document that they have to create a
> > postgres@template1 user before flipping the switch.  That way, there is
> > no special user, no PG_INSTALLER file, and no double-tests for user
> > names.
> 
> ... and no useful superuser account; if you can't connect to anything
> except template1 then you ain't much of a superuser.
> 
> To get around that you'd have to create postgres@db1, postgres@db2,
> postgres@db3, etc etc.  This would be a huge pain in the neck; I think
> it'd render the scheme impractical.  (Keep in mind that anybody who'd be
> interested in this feature at all has probably got quite a number of
> databases to contend with.)

Yes, I hear you, but that brings us around full-circle to the original
patch with one super-user who is the install user. 

I don't know where else to go with the patch at this point.  I think
increasing the number of 'global' users is polluting the namespace too
much, and having none seems to be unappealing.  This is why I am back to
just the install user.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073

Re: Open 7.3 items

From

Tom Lane

Date:

14 August 2002, 22:58:37

Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I don't know where else to go with the patch at this point.  I think
> increasing the number of 'global' users is polluting the namespace too
> much,

Why?  If the installation needs N global users, then it needs N global
users; who are you to make that value judgment for them?

In practice I think an installation that's using this feature is going
to have a pretty small number of global users, and so the issue of
collisions with local usernames isn't really as big as it's been painted
in this thread.  We could ignore that issue (except for documenting it)
and have a perfectly serviceable feature.

But I don't think it's a wise idea to design the thing in a way that
makes it impossible to have more than one global user.

If you don't like including all the pg_shadow entries in the flat file
(though I really don't see any problem with that), could we replace
PG_INSTALL with a pg_global_users config file that lists the global user
names?  I think it would be good enough to let this be hand-maintained,
with initdb initializing it to contain the install user's name.
        regards, tom lane

Re: Open 7.3 items

From

Vince Vielhaber

Date:

14 August 2002, 22:59:37

On Wed, 14 Aug 2002, Bruce Momjian wrote:

> Tom Lane wrote:
> > Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > > How about if we just document that they have to create a
> > > postgres@template1 user before flipping the switch.  That way, there is
> > > no special user, no PG_INSTALLER file, and no double-tests for user
> > > names.
> >
> > ... and no useful superuser account; if you can't connect to anything
> > except template1 then you ain't much of a superuser.
> >
> > To get around that you'd have to create postgres@db1, postgres@db2,
> > postgres@db3, etc etc.  This would be a huge pain in the neck; I think
> > it'd render the scheme impractical.  (Keep in mind that anybody who'd be
> > interested in this feature at all has probably got quite a number of
> > databases to contend with.)
>
> Yes, I hear you, but that brings us around full-circle to the original
> patch with one super-user who is the install user.
>
> I don't know where else to go with the patch at this point.  I think
> increasing the number of 'global' users is polluting the namespace too
> much, and having none seems to be unappealing.  This is why I am back to
> just the install user.

I wouldn't be in favor of that.

Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH    email: vev@michvhf.com    http://www.pop4.net        56K Nationwide Dialup from $16.00/mo
atPop4 Networking     http://www.camping-usa.com      http://www.cloudninegifts.com  http://www.meanstreamradio.com
 http://www.unknown-artists.com
 
==========================================================================

Re: Open 7.3 items

From

Bruce Momjian

Date:

14 August 2002, 23:30:56

Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > I don't know where else to go with the patch at this point.  I think
> > increasing the number of 'global' users is polluting the namespace too
> > much,
> 
> Why?  If the installation needs N global users, then it needs N global
> users; who are you to make that value judgment for them?
> 
> In practice I think an installation that's using this feature is going
> to have a pretty small number of global users, and so the issue of
> collisions with local usernames isn't really as big as it's been painted
> in this thread.  We could ignore that issue (except for documenting it)
> and have a perfectly serviceable feature.

The original idea was that Marc wanted people who could create their own
users for their own databases.  If we make the creation of global users
too easy, all of a sudden people don't have control over their db
usernames because they have to avoid all the global user names already
defined.  By adding multiple global users, it is diluting the usefulness
of the feature.

I suppose a pg_global_users file would be a compromise because only the
admin could actually add people to that file.  If it was more automatic,
like writing pg_shadow, someone could create a user without an @ and
block access for other users to other database, which is bad.

I still don't like the fact that people think they have control over
their db namespace, when they really don't, but no one else seems to see
that as a problem.  The namespace conflicts just yell of poor design.

OK, I have another idea.  What if we make global users end with an @, so
dave@ is a global user.  We can easily check for that in the postmaster
and not append the dbname.  I know it makes @ a special character, but
considering the problem of namespace collision, it seems better than
what we have now.  We could add the install user too if we wish, or just
tell them to make sure they add a user@ before turning on the feature.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073

Re: Open 7.3 items

From

ngpg@grymmjack.com

Date:

15 August 2002, 00:57:55

pgman@candle.pha.pa.us (Bruce Momjian) wrote:
> Tom Lane wrote:
>> Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> > I don't know where else to go with the patch at this point.  I
>> > think increasing the number of 'global' users is polluting the
>> > namespace too much,
>> 
>> Why?  If the installation needs N global users, then it needs N
>> global users; who are you to make that value judgment for them?
>> 
>> In practice I think an installation that's using this feature is
>> going to have a pretty small number of global users, and so the issue
>> of collisions with local usernames isn't really as big as it's been
>> painted in this thread.  We could ignore that issue (except for
>> documenting it) and have a perfectly serviceable feature.
> 
> The original idea was that Marc wanted people who could create their
> own users for their own databases.  If we make the creation of global
> users too easy, all of a sudden people don't have control over their
> db usernames because they have to avoid all the global user names
> already defined.  By adding multiple global users, it is diluting the
> usefulness of the feature.
> 

Maybe I am missing something here but shouldnt db access really be part
of the privileges system?  If all we are talking about is a quick hack
until this can be implemented correctly, what is the concern with having
so much functionality in the hack?  Why does it matter what the actual
usernames can or cant be?  For example you could just make everyone with
a username NNNNNN@dbname (where N's are int) local accounts and then
leave everything else alone.  The only issue I could see with something
like this would be that someone trying to use this hack wont be able to
give their users names like pudgy@dbname, but who cares?  I mean if you
are giving access to a bunch of developers, how is it going to affect
them if you tell them to login with 123456@yourdb instead of
jsmith@yourdb?  If they cant remember it or something maybe they can
write it down?  I dunno...

Re: Open 7.3 items

From

Joe Conway

Date:

15 August 2002, 05:13:17

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

Re: Open 7.3 items

From

Mike Mascari

Date:

15 August 2002, 06:38:06

Joe Conway wrote:
> 
> Hannu Krosing wrote:
> > What about functions
> >
> > 1. split(text,text,int) returns text
> >
> > 2. split(text,text) returns text[]
> >
> > and why not
> >
> > 3. split(text,text,text) returns text
> >
> > which returns text from $1 delimited by $2 and $3
> 
> Given the time remaining before beta, I'll be happy just to get #1 done.
> 
> I can see the utility of #2 (or perhaps even a table function which
> breaks the string into individual rows). I'm not sure I understand #3.
> 
> I am concerned about the name though -- only in that there are usually
> objections raised to function names that are too likely to conflict with
> user created function names. But "split" is good from the standpoint
> that it is used in other languages, so people should find it familiar.
> 
> Anyone have comments on the name?

Actually, I've been wondering if it wouldn't be a good idea with schemas
coming to think now about how to divide up namespaces for all sorts of
things, including PostgreSQL's built in functions, the contrib code,
etc. I think a naming scheme with which both PostgreSQL and the
community would comply, a la Java's reverse DNS scheme for namespaces
would be neat. So when a database is installed, the following schemas
are automatically created:

org.postgresql.system <- System tables and core functions
org.postgresql.text <- Text related functions
org.postgresql.math <- Math related functions
org.postgresql.fts <- Full-Text schema

or perhaps:

org.postgresql.contrib.fts <- Full-Text schema

etc.

I don't even know if "." is allowed in the schema names, but you get the
idea. Then, a users search_path (or whatever it's called, I haven't used
the development version in a while), would be the equivalent of Java's
"import" statement, or C++'s "using" statement. So "split" would be a
function in the org.postgresql.text schema.

How about them apples?

If this is an insane idea, its 3:32 A.M. my time ;-)

Mike Mascari
mascarm@mascari.com

> 
> Joe

Re: Open 7.3 items

From

Tom Lane

Date:

15 August 2002, 12:19:10

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

Re: Open 7.3 items

From

Michael Meskes

Date:

15 August 2002, 13:22:09

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!

Re: Open 7.3 items

From

Bruce Momjian

Date:

15 August 2002, 14:54:30

OK, no one complained/commented on my idea of having global users have a
trailing '@', so here is a patch that implements that.  It has the
advantages of:

    no special install user (create global user before enabling feature)
    no /data/PG_INSTALLER file
    allows multiple global users to be easily added
    no namespace collisions because globals have a trailing @
    easy for postmaster to recognize global users
    no double-user lookups of pg_pwd changes
    very small patch footprint

The only downside is that it treats '@' as a special character when it
is enabled, but frankly, because we are appending @dbname anyway, having
'@' as a special character in that case makes sense.

Comments?

---------------------------------------------------------------------------

Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > > I don't know where else to go with the patch at this point.  I think
> > > increasing the number of 'global' users is polluting the namespace too
> > > much,
> >
> > Why?  If the installation needs N global users, then it needs N global
> > users; who are you to make that value judgment for them?
> >
> > In practice I think an installation that's using this feature is going
> > to have a pretty small number of global users, and so the issue of
> > collisions with local usernames isn't really as big as it's been painted
> > in this thread.  We could ignore that issue (except for documenting it)
> > and have a perfectly serviceable feature.
>
> The original idea was that Marc wanted people who could create their own
> users for their own databases.  If we make the creation of global users
> too easy, all of a sudden people don't have control over their db
> usernames because they have to avoid all the global user names already
> defined.  By adding multiple global users, it is diluting the usefulness
> of the feature.
>
> I suppose a pg_global_users file would be a compromise because only the
> admin could actually add people to that file.  If it was more automatic,
> like writing pg_shadow, someone could create a user without an @ and
> block access for other users to other database, which is bad.
>
> I still don't like the fact that people think they have control over
> their db namespace, when they really don't, but no one else seems to see
> that as a problem.  The namespace conflicts just yell of poor design.
>
> OK, I have another idea.  What if we make global users end with an @, so
> dave@ is a global user.  We can easily check for that in the postmaster
> and not append the dbname.  I know it makes @ a special character, but
> considering the problem of namespace collision, it seems better than
> what we have now.  We could add the install user too if we wish, or just
> tell them to make sure they add a user@ before turning on the feature.
>
> --
>   Bruce Momjian                        |  http://candle.pha.pa.us
>   pgman@candle.pha.pa.us               |  (610) 359-1001
>   +  If your life is a hard drive,     |  13 Roberts Road
>   +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073
Index: doc/src/sgml/runtime.sgml
===================================================================
RCS file: /cvsroot/pgsql-server/doc/src/sgml/runtime.sgml,v
retrieving revision 1.125
diff -c -r1.125 runtime.sgml
*** doc/src/sgml/runtime.sgml    15 Aug 2002 14:26:15 -0000    1.125
--- doc/src/sgml/runtime.sgml    15 Aug 2002 15:32:29 -0000
***************
*** 1191,1196 ****
--- 1191,1211 ----
       </varlistentry>

       <varlistentry>
+       <term><varname>DB_USER_NAMESPACE</varname> (<type>boolean</type>)</term>
+       <listitem>
+        <para>
+         Appends <literal>@</> and the database name to the user name when
+         connecting to the database.  This allows per-database users.
+         User names ending with <literal>@</> are considered global and may
+         connect to any database.  It is recommended you create at least one
+         global user, e.g. <literal>postgres@</>, before enabling this feature.
+         Also, when creating user names containing <literal>@</>, you will need
+         to quote the user name.
+        </para>
+       </listitem>
+      </varlistentry>
+
+      <varlistentry>
        <indexterm>
         <primary>deadlock</primary>
         <secondary>timeout</secondary>
Index: src/backend/libpq/auth.c
===================================================================
RCS file: /cvsroot/pgsql-server/src/backend/libpq/auth.c,v
retrieving revision 1.82
diff -c -r1.82 auth.c
*** src/backend/libpq/auth.c    20 Jun 2002 20:29:28 -0000    1.82
--- src/backend/libpq/auth.c    15 Aug 2002 15:32:30 -0000
***************
*** 117,123 ****
               version, PG_KRB4_VERSION);
          return STATUS_ERROR;
      }
!     if (strncmp(port->user, auth_data.pname, SM_USER) != 0)
      {
          elog(LOG, "pg_krb4_recvauth: name \"%s\" != \"%s\"",
               port->user, auth_data.pname);
--- 117,123 ----
               version, PG_KRB4_VERSION);
          return STATUS_ERROR;
      }
!     if (strncmp(port->user, auth_data.pname, SM_DATABASE_USER) != 0)
      {
          elog(LOG, "pg_krb4_recvauth: name \"%s\" != \"%s\"",
               port->user, auth_data.pname);
***************
*** 290,296 ****
      }

      kusername = pg_an_to_ln(kusername);
!     if (strncmp(port->user, kusername, SM_USER))
      {
          elog(LOG, "pg_krb5_recvauth: user name \"%s\" != krb5 name \"%s\"",
               port->user, kusername);
--- 290,296 ----
      }

      kusername = pg_an_to_ln(kusername);
!     if (strncmp(port->user, kusername, SM_DATABASE_USER))
      {
          elog(LOG, "pg_krb5_recvauth: user name \"%s\" != krb5 name \"%s\"",
               port->user, kusername);
Index: src/backend/postmaster/postmaster.c
===================================================================
RCS file: /cvsroot/pgsql-server/src/backend/postmaster/postmaster.c,v
retrieving revision 1.283
diff -c -r1.283 postmaster.c
*** src/backend/postmaster/postmaster.c    10 Aug 2002 20:29:18 -0000    1.283
--- src/backend/postmaster/postmaster.c    15 Aug 2002 15:32:34 -0000
***************
*** 116,122 ****
  sigset_t    UnBlockSig,
              BlockSig,
              AuthBlockSig;
-
  #else
  int            UnBlockSig,
              BlockSig,
--- 116,121 ----
***************
*** 191,196 ****
--- 190,197 ----
  bool        HostnameLookup;        /* for ps display */
  bool        ShowPortNumber;
  bool        Log_connections = false;
+ bool        Db_user_namespace = false;
+

  /* Startup/shutdown state */
  static pid_t StartupPID = 0,
***************
*** 1161,1166 ****
--- 1162,1177 ----
      if (port->user[0] == '\0')
          elog(FATAL, "no PostgreSQL user name specified in startup packet");

+     /* Append database name for per-db user namespace, exclude global users. */
+     if (Db_user_namespace && strlen(port->user) > 0 &&
+         port->user[strlen(port->user)-1] != '@')
+     {
+         char hold_user[SM_DATABASE_USER];
+         snprintf(hold_user, SM_DATABASE_USER, "%s@%s", port->user,
+                  port->database);
+         strcpy(port->user, hold_user);
+     }
+
      /*
       * If we're going to reject the connection due to database state, say
       * so now instead of wasting cycles on an authentication exchange.
***************
*** 2587,2597 ****
      if (FindExec(fullprogname, argv[0], "postmaster") < 0)
          return false;

!     filename = palloc(strlen(DataDir) + 20);
      sprintf(filename, "%s/postmaster.opts", DataDir);

!     fp = fopen(filename, "w");
!     if (fp == NULL)
      {
          postmaster_error("cannot create file %s: %s",
                           filename, strerror(errno));
--- 2598,2607 ----
      if (FindExec(fullprogname, argv[0], "postmaster") < 0)
          return false;

!     filename = palloc(strlen(DataDir) + 17);
      sprintf(filename, "%s/postmaster.opts", DataDir);

!     if ((fp = fopen(filename, "w")) == NULL)
      {
          postmaster_error("cannot create file %s: %s",
                           filename, strerror(errno));
Index: src/backend/utils/misc/guc.c
===================================================================
RCS file: /cvsroot/pgsql-server/src/backend/utils/misc/guc.c,v
retrieving revision 1.82
diff -c -r1.82 guc.c
*** src/backend/utils/misc/guc.c    15 Aug 2002 02:51:26 -0000    1.82
--- src/backend/utils/misc/guc.c    15 Aug 2002 15:32:42 -0000
***************
*** 483,488 ****
--- 483,492 ----
          { "transform_null_equals", PGC_USERSET }, &Transform_null_equals,
          false, NULL, NULL
      },
+     {
+         { "db_user_namespace", PGC_SIGHUP }, &Db_user_namespace,
+         false, NULL, NULL
+     },

      {
          { NULL, 0 }, NULL, false, NULL, NULL
Index: src/backend/utils/misc/postgresql.conf.sample
===================================================================
RCS file: /cvsroot/pgsql-server/src/backend/utils/misc/postgresql.conf.sample,v
retrieving revision 1.44
diff -c -r1.44 postgresql.conf.sample
*** src/backend/utils/misc/postgresql.conf.sample    12 Aug 2002 00:36:12 -0000    1.44
--- src/backend/utils/misc/postgresql.conf.sample    15 Aug 2002 15:32:42 -0000
***************
*** 113,119 ****
  #
  #    Message display
  #
-
  #server_min_messages = notice    # Values, in order of decreasing detail:
                  #   debug5, debug4, debug3, debug2, debug1,
                  #   info, notice, warning, error, log, fatal,
--- 113,118 ----
***************
*** 201,203 ****
--- 200,203 ----
  #sql_inheritance = true
  #transform_null_equals = false
  #statement_timeout = 0                # 0 is disabled
+ #db_user_namespace = false
Index: src/include/libpq/libpq-be.h
===================================================================
RCS file: /cvsroot/pgsql-server/src/include/libpq/libpq-be.h,v
retrieving revision 1.32
diff -c -r1.32 libpq-be.h
*** src/include/libpq/libpq-be.h    20 Jun 2002 20:29:49 -0000    1.32
--- src/include/libpq/libpq-be.h    15 Aug 2002 15:32:43 -0000
***************
*** 59,65 ****

      ProtocolVersion proto;
      char        database[SM_DATABASE + 1];
!     char        user[SM_USER + 1];
      char        options[SM_OPTIONS + 1];
      char        tty[SM_TTY + 1];
      char        auth_arg[MAX_AUTH_ARG];
--- 59,65 ----

      ProtocolVersion proto;
      char        database[SM_DATABASE + 1];
!     char        user[SM_DATABASE_USER + 1];
      char        options[SM_OPTIONS + 1];
      char        tty[SM_TTY + 1];
      char        auth_arg[MAX_AUTH_ARG];
***************
*** 72,78 ****
      SSL           *ssl;
      X509       *peer;
      char        peer_dn[128 + 1];
!     char        peer_cn[SM_USER + 1];
      unsigned long count;
  #endif
  } Port;
--- 72,78 ----
      SSL           *ssl;
      X509       *peer;
      char        peer_dn[128 + 1];
!     char        peer_cn[SM_DATABASE_USER + 1];
      unsigned long count;
  #endif
  } Port;
Index: src/include/libpq/pqcomm.h
===================================================================
RCS file: /cvsroot/pgsql-server/src/include/libpq/pqcomm.h,v
retrieving revision 1.65
diff -c -r1.65 pqcomm.h
*** src/include/libpq/pqcomm.h    12 Aug 2002 14:35:26 -0000    1.65
--- src/include/libpq/pqcomm.h    15 Aug 2002 15:32:43 -0000
***************
*** 114,119 ****
--- 114,121 ----
  #define SM_DATABASE        64
  /* SM_USER should be the same size as the others.  bjm 2002-06-02 */
  #define SM_USER            32
+ /* We append database name if db_user_namespace true. */
+ #define SM_DATABASE_USER (SM_DATABASE+SM_USER)
  #define SM_OPTIONS        64
  #define SM_UNUSED        64
  #define SM_TTY            64
***************
*** 124,135 ****
--- 126,139 ----
  {
      ProtocolVersion protoVersion;        /* Protocol version */
      char        database[SM_DATABASE];    /* Database name */
+                 /* Db_user_namespace appends dbname */
      char        user[SM_USER];    /* User name */
      char        options[SM_OPTIONS];    /* Optional additional args */
      char        unused[SM_UNUSED];        /* Unused */
      char        tty[SM_TTY];    /* Tty for debug output */
  } StartupPacket;

+ extern bool Db_user_namespace;

  /* These are the authentication requests sent by the backend. */

Re: Open 7.3 items

From

Vince Vielhaber

Date:

15 August 2002, 15:06:32

On Thu, 15 Aug 2002, Bruce Momjian wrote:

>
> OK, no one complained/commented on my idea of having global users have a
> trailing '@', so here is a patch that implements that.  It has the
> advantages of:

Probably because not everyone saw it.  I know I didn't.  This entire
issue is growing more and more complex.  How about a configure item
to not even compile it in?  Or better yet, a configure item to put
it there with the default off.

Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH    email: vev@michvhf.com    http://www.pop4.net        56K Nationwide Dialup from $16.00/mo
atPop4 Networking     http://www.camping-usa.com      http://www.cloudninegifts.com  http://www.meanstreamradio.com
 http://www.unknown-artists.com

==========================================================================

Re: Open 7.3 items

From

Bruce Momjian

Date:

15 August 2002, 15:13:32

Vince, you were in the CC, and it went to hackers:Message 772/835 Bruce Momjian
                 Aug 14, 2002 08:30:47 pm -0400Subject: Re: [HACKERS] Open 7.3 itemsTo: Tom Lane
<tgl@sss.pgh.pa.us>Date:Wed, 14 Aug 2002 20:30:47 -0400 (EDT)cc: Lamar Owen <lamar.owen@wgcr.org>, Vince Vielhaber
<vev@michvhf.com>,          PostgreSQL-development <pgsql-hackers@postgresql.org>X-Virus-Scanned: by AMaViS
new-20020517Precedence:bulkSender: pgsql-hackers-owner@postgresql.orgX-Virus-Scanned: by AMaViS new-20020517
 

---------------------------------------------------------------------------

Vince Vielhaber wrote:
> On Thu, 15 Aug 2002, Bruce Momjian wrote:
> 
> >
> > OK, no one complained/commented on my idea of having global users have a
> > trailing '@', so here is a patch that implements that.  It has the
> > advantages of:
> 
> Probably because not everyone saw it.  I know I didn't.  This entire
> issue is growing more and more complex.  How about a configure item
> to not even compile it in?  Or better yet, a configure item to put
> it there with the default off.
> 
> Vince.
> -- 
> ==========================================================================
> Vince Vielhaber -- KA8CSH    email: vev@michvhf.com    http://www.pop4.net
>          56K Nationwide Dialup from $16.00/mo at Pop4 Networking
>       http://www.camping-usa.com      http://www.cloudninegifts.com
>    http://www.meanstreamradio.com       http://www.unknown-artists.com
> ==========================================================================
> 
> 
> 
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073

Re: Open 7.3 items

From

Bruce Momjian

Date:

15 August 2002, 15:16:37

Vince Vielhaber wrote:
> On Thu, 15 Aug 2002, Bruce Momjian wrote:
> 
> >
> > OK, no one complained/commented on my idea of having global users have a
> > trailing '@', so here is a patch that implements that.  It has the
> > advantages of:
> 
> Probably because not everyone saw it.  I know I didn't.  This entire
> issue is growing more and more complex.  How about a configure item
> to not even compile it in?  Or better yet, a configure item to put
> it there with the default off.

I think I am prety close, and I don't see a configure flag as any better
than a GUC option that is off by default.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073

Re: Open 7.3 items

From

Vince Vielhaber

Date:

15 August 2002, 15:34:41

On Thu, 15 Aug 2002, Bruce Momjian wrote:

>
> Vince, you were in the CC, and it went to hackers:

Oh, I'm not saying I didn't get it, I'm saying I didn't see it in
the message.  It looked as if you were only replying to Tom so after
reading the jist of it I moved on.  When you included it a little
while ago I wondered what you were referring to so I read the whole
thing more carefully and realized that I missed the end.

Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH    email: vev@michvhf.com    http://www.pop4.net        56K Nationwide Dialup from $16.00/mo
atPop4 Networking     http://www.camping-usa.com      http://www.cloudninegifts.com  http://www.meanstreamradio.com
 http://www.unknown-artists.com

==========================================================================

Re: Open 7.3 items

From

Vince Vielhaber

Date:

15 August 2002, 15:38:45

On Thu, 15 Aug 2002, Bruce Momjian wrote:

> Vince Vielhaber wrote:
> > On Thu, 15 Aug 2002, Bruce Momjian wrote:
> >
> > >
> > > OK, no one complained/commented on my idea of having global users have a
> > > trailing '@', so here is a patch that implements that.  It has the
> > > advantages of:
> >
> > Probably because not everyone saw it.  I know I didn't.  This entire
> > issue is growing more and more complex.  How about a configure item
> > to not even compile it in?  Or better yet, a configure item to put
> > it there with the default off.
>
> I think I am prety close, and I don't see a configure flag as any better
> than a GUC option that is off by default.

But how many people would even use it?  I can't see adding the bloat
unnecessarily and risking it accidently being turned on.  Am I wrong
and really alot of people actually want/need this?

Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH    email: vev@michvhf.com    http://www.pop4.net        56K Nationwide Dialup from $16.00/mo
atPop4 Networking     http://www.camping-usa.com      http://www.cloudninegifts.com  http://www.meanstreamradio.com
 http://www.unknown-artists.com
 
==========================================================================

Re: Open 7.3 items

From

Bruce Momjian

Date:

15 August 2002, 15:41:18

Vince Vielhaber wrote:
> On Thu, 15 Aug 2002, Bruce Momjian wrote:
> 
> > Vince Vielhaber wrote:
> > > On Thu, 15 Aug 2002, Bruce Momjian wrote:
> > >
> > > >
> > > > OK, no one complained/commented on my idea of having global users have a
> > > > trailing '@', so here is a patch that implements that.  It has the
> > > > advantages of:
> > >
> > > Probably because not everyone saw it.  I know I didn't.  This entire
> > > issue is growing more and more complex.  How about a configure item
> > > to not even compile it in?  Or better yet, a configure item to put
> > > it there with the default off.
> >
> > I think I am prety close, and I don't see a configure flag as any better
> > than a GUC option that is off by default.
> 
> But how many people would even use it?  I can't see adding the bloat
> unnecessarily and risking it accidently being turned on.  Am I wrong
> and really alot of people actually want/need this?

Well, the demand seems to be larger than I thought, considering the
number of people who have chimed in and want certain features, like
multiple global users.  I see this being using more by ISP's and
universities that need better user/db partitioning.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073

Re: Open 7.3 items

From

Vince Vielhaber

Date:

15 August 2002, 15:50:57

On Thu, 15 Aug 2002, Bruce Momjian wrote:

> Vince Vielhaber wrote:
> > On Thu, 15 Aug 2002, Bruce Momjian wrote:
> >
> > > Vince Vielhaber wrote:
> > > > On Thu, 15 Aug 2002, Bruce Momjian wrote:
> > > >
> > > > >
> > > > > OK, no one complained/commented on my idea of having global users have a
> > > > > trailing '@', so here is a patch that implements that.  It has the
> > > > > advantages of:
> > > >
> > > > Probably because not everyone saw it.  I know I didn't.  This entire
> > > > issue is growing more and more complex.  How about a configure item
> > > > to not even compile it in?  Or better yet, a configure item to put
> > > > it there with the default off.
> > >
> > > I think I am prety close, and I don't see a configure flag as any better
> > > than a GUC option that is off by default.
> >
> > But how many people would even use it?  I can't see adding the bloat
> > unnecessarily and risking it accidently being turned on.  Am I wrong
> > and really alot of people actually want/need this?
>
> Well, the demand seems to be larger than I thought, considering the
> number of people who have chimed in and want certain features, like
> multiple global users.  I see this being using more by ISP's and
> universities that need better user/db partitioning.

I don't know that concern over a possible limited number of global
users is directly proportional to the desire for the feature.

Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH    email: vev@michvhf.com    http://www.pop4.net        56K Nationwide Dialup from $16.00/mo
atPop4 Networking     http://www.camping-usa.com      http://www.cloudninegifts.com  http://www.meanstreamradio.com
 http://www.unknown-artists.com
 
==========================================================================

Re: Open 7.3 items

From

Tom Lane

Date:

15 August 2002, 15:56:50

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

Re: Open 7.3 items

From

Vince Vielhaber

Date:

15 August 2002, 16:00:44

On Thu, 15 Aug 2002, Tom Lane wrote:

> Other than getting the array sizes right, it does look like a nice
> patch; very small, which is what I'd hoped for.  The notion of having to
> say "postgres@" still seems kinda ugly, but given the simplicity of the
> patch I'm willing to live with that.

Going from postgres to postgres@ ???  I don't care how simple the patch
is, I'd rather it was configurable to keep it out completely.  That's
not just ugly, that's coyote ugly!

Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH    email: vev@michvhf.com    http://www.pop4.net        56K Nationwide Dialup from $16.00/mo
atPop4 Networking     http://www.camping-usa.com      http://www.cloudninegifts.com  http://www.meanstreamradio.com
 http://www.unknown-artists.com
 
==========================================================================

Re: Open 7.3 items

From

Lamar Owen

Date:

15 August 2002, 16:04:25

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

Re: Open 7.3 items

From

Tom Lane

Date:

15 August 2002, 16:07:41

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

Re: Open 7.3 items

From

Vince Vielhaber

Date:

15 August 2002, 16:13:59

On Thu, 15 Aug 2002, Tom Lane wrote:

> Vince Vielhaber <vev@michvhf.com> writes:
> > Going from postgres to postgres@ ???  I don't care how simple the patch
> > is, I'd rather it was configurable to keep it out completely.  That's
> > not just ugly, that's coyote ugly!
>
> Yeah, but it doesn't affect you unless you turn on the GUC parameter.
> Most people will never even know this code is there.

But it doesn't need to affect anyone, even if it's enabled.  Isn't
the lack of an @ just as good as an @ at the end of the username?
Gets rid of the ugliness and won't break things if it's suddenly
enabled.

Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH    email: vev@michvhf.com    http://www.pop4.net        56K Nationwide Dialup from $16.00/mo
atPop4 Networking     http://www.camping-usa.com      http://www.cloudninegifts.com  http://www.meanstreamradio.com
 http://www.unknown-artists.com
 
==========================================================================

Re: Open 7.3 items

From

Tom Lane

Date:

15 August 2002, 16:21:38

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

Re: Open 7.3 items

From

Bruce Momjian

Date:

15 August 2002, 16:43:20

Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > + /* We append database name if db_user_namespace true. */
> > + #define SM_DATABASE_USER (SM_DATABASE+SM_USER)
>
> Is this calculation correct?  I'd think you'd need at least one more
> character to allow for the "@".  And I'm not sure about whether trailing
> nulls are or need to be counted.  There seem to be some places in your
> patch where things are dimensioned SM_DATABASE_USER and some where it's
> SM_DATABASE_USER+1; why the inconsistency, and which is right?

Yes, there was some inconsistency.  The new patch fixes that up;
attached.

> Other than getting the array sizes right, it does look like a nice
> patch; very small, which is what I'd hoped for.  The notion of having to
> say "postgres@" still seems kinda ugly, but given the simplicity of the
> patch I'm willing to live with that.

Glad we have something now everyone likes, or at least can live with.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073
Index: doc/src/sgml/runtime.sgml
===================================================================
RCS file: /cvsroot/pgsql-server/doc/src/sgml/runtime.sgml,v
retrieving revision 1.125
diff -c -r1.125 runtime.sgml
*** doc/src/sgml/runtime.sgml    15 Aug 2002 14:26:15 -0000    1.125
--- doc/src/sgml/runtime.sgml    15 Aug 2002 16:34:12 -0000
***************
*** 1191,1196 ****
--- 1191,1211 ----
       </varlistentry>

       <varlistentry>
+       <term><varname>DB_USER_NAMESPACE</varname> (<type>boolean</type>)</term>
+       <listitem>
+        <para>
+         Appends <literal>@</> and the database name to the user name when
+         connecting to the database.  This allows per-database users.
+         User names ending with <literal>@</> are considered global and may
+         connect to any database.  It is recommended you create at least one
+         global user, e.g. <literal>postgres@</>, before enabling this feature.
+         Also, when creating user names containing <literal>@</>, you will need
+         to quote the user name.
+        </para>
+       </listitem>
+      </varlistentry>
+
+      <varlistentry>
        <indexterm>
         <primary>deadlock</primary>
         <secondary>timeout</secondary>
Index: src/backend/libpq/auth.c
===================================================================
RCS file: /cvsroot/pgsql-server/src/backend/libpq/auth.c,v
retrieving revision 1.82
diff -c -r1.82 auth.c
*** src/backend/libpq/auth.c    20 Jun 2002 20:29:28 -0000    1.82
--- src/backend/libpq/auth.c    15 Aug 2002 16:34:13 -0000
***************
*** 117,123 ****
               version, PG_KRB4_VERSION);
          return STATUS_ERROR;
      }
!     if (strncmp(port->user, auth_data.pname, SM_USER) != 0)
      {
          elog(LOG, "pg_krb4_recvauth: name \"%s\" != \"%s\"",
               port->user, auth_data.pname);
--- 117,123 ----
               version, PG_KRB4_VERSION);
          return STATUS_ERROR;
      }
!     if (strncmp(port->user, auth_data.pname, SM_DATABASE_USER) != 0)
      {
          elog(LOG, "pg_krb4_recvauth: name \"%s\" != \"%s\"",
               port->user, auth_data.pname);
***************
*** 290,296 ****
      }

      kusername = pg_an_to_ln(kusername);
!     if (strncmp(port->user, kusername, SM_USER))
      {
          elog(LOG, "pg_krb5_recvauth: user name \"%s\" != krb5 name \"%s\"",
               port->user, kusername);
--- 290,296 ----
      }

      kusername = pg_an_to_ln(kusername);
!     if (strncmp(port->user, kusername, SM_DATABASE_USER))
      {
          elog(LOG, "pg_krb5_recvauth: user name \"%s\" != krb5 name \"%s\"",
               port->user, kusername);
Index: src/backend/postmaster/postmaster.c
===================================================================
RCS file: /cvsroot/pgsql-server/src/backend/postmaster/postmaster.c,v
retrieving revision 1.283
diff -c -r1.283 postmaster.c
*** src/backend/postmaster/postmaster.c    10 Aug 2002 20:29:18 -0000    1.283
--- src/backend/postmaster/postmaster.c    15 Aug 2002 16:34:15 -0000
***************
*** 116,122 ****
  sigset_t    UnBlockSig,
              BlockSig,
              AuthBlockSig;
-
  #else
  int            UnBlockSig,
              BlockSig,
--- 116,121 ----
***************
*** 191,196 ****
--- 190,197 ----
  bool        HostnameLookup;        /* for ps display */
  bool        ShowPortNumber;
  bool        Log_connections = false;
+ bool        Db_user_namespace = false;
+

  /* Startup/shutdown state */
  static pid_t StartupPID = 0,
***************
*** 1161,1166 ****
--- 1162,1177 ----
      if (port->user[0] == '\0')
          elog(FATAL, "no PostgreSQL user name specified in startup packet");

+     /* Append database name for per-db user namespace, exclude global users. */
+     if (Db_user_namespace && strlen(port->user) > 0 &&
+         port->user[strlen(port->user)-1] != '@')
+     {
+         char hold_user[SM_DATABASE_USER+1];
+         snprintf(hold_user, SM_DATABASE_USER+1, "%s@%s", port->user,
+                  port->database);
+         strcpy(port->user, hold_user);
+     }
+
      /*
       * If we're going to reject the connection due to database state, say
       * so now instead of wasting cycles on an authentication exchange.
***************
*** 2587,2597 ****
      if (FindExec(fullprogname, argv[0], "postmaster") < 0)
          return false;

!     filename = palloc(strlen(DataDir) + 20);
      sprintf(filename, "%s/postmaster.opts", DataDir);

!     fp = fopen(filename, "w");
!     if (fp == NULL)
      {
          postmaster_error("cannot create file %s: %s",
                           filename, strerror(errno));
--- 2598,2607 ----
      if (FindExec(fullprogname, argv[0], "postmaster") < 0)
          return false;

!     filename = palloc(strlen(DataDir) + 17);
      sprintf(filename, "%s/postmaster.opts", DataDir);

!     if ((fp = fopen(filename, "w")) == NULL)
      {
          postmaster_error("cannot create file %s: %s",
                           filename, strerror(errno));
Index: src/backend/utils/misc/guc.c
===================================================================
RCS file: /cvsroot/pgsql-server/src/backend/utils/misc/guc.c,v
retrieving revision 1.82
diff -c -r1.82 guc.c
*** src/backend/utils/misc/guc.c    15 Aug 2002 02:51:26 -0000    1.82
--- src/backend/utils/misc/guc.c    15 Aug 2002 16:34:17 -0000
***************
*** 483,488 ****
--- 483,492 ----
          { "transform_null_equals", PGC_USERSET }, &Transform_null_equals,
          false, NULL, NULL
      },
+     {
+         { "db_user_namespace", PGC_SIGHUP }, &Db_user_namespace,
+         false, NULL, NULL
+     },

      {
          { NULL, 0 }, NULL, false, NULL, NULL
Index: src/backend/utils/misc/postgresql.conf.sample
===================================================================
RCS file: /cvsroot/pgsql-server/src/backend/utils/misc/postgresql.conf.sample,v
retrieving revision 1.44
diff -c -r1.44 postgresql.conf.sample
*** src/backend/utils/misc/postgresql.conf.sample    12 Aug 2002 00:36:12 -0000    1.44
--- src/backend/utils/misc/postgresql.conf.sample    15 Aug 2002 16:34:17 -0000
***************
*** 113,119 ****
  #
  #    Message display
  #
-
  #server_min_messages = notice    # Values, in order of decreasing detail:
                  #   debug5, debug4, debug3, debug2, debug1,
                  #   info, notice, warning, error, log, fatal,
--- 113,118 ----
***************
*** 201,203 ****
--- 200,203 ----
  #sql_inheritance = true
  #transform_null_equals = false
  #statement_timeout = 0                # 0 is disabled
+ #db_user_namespace = false
Index: src/include/libpq/libpq-be.h
===================================================================
RCS file: /cvsroot/pgsql-server/src/include/libpq/libpq-be.h,v
retrieving revision 1.32
diff -c -r1.32 libpq-be.h
*** src/include/libpq/libpq-be.h    20 Jun 2002 20:29:49 -0000    1.32
--- src/include/libpq/libpq-be.h    15 Aug 2002 16:34:18 -0000
***************
*** 59,65 ****

      ProtocolVersion proto;
      char        database[SM_DATABASE + 1];
!     char        user[SM_USER + 1];
      char        options[SM_OPTIONS + 1];
      char        tty[SM_TTY + 1];
      char        auth_arg[MAX_AUTH_ARG];
--- 59,65 ----

      ProtocolVersion proto;
      char        database[SM_DATABASE + 1];
!     char        user[SM_DATABASE_USER + 1];
      char        options[SM_OPTIONS + 1];
      char        tty[SM_TTY + 1];
      char        auth_arg[MAX_AUTH_ARG];
Index: src/include/libpq/pqcomm.h
===================================================================
RCS file: /cvsroot/pgsql-server/src/include/libpq/pqcomm.h,v
retrieving revision 1.65
diff -c -r1.65 pqcomm.h
*** src/include/libpq/pqcomm.h    12 Aug 2002 14:35:26 -0000    1.65
--- src/include/libpq/pqcomm.h    15 Aug 2002 16:34:18 -0000
***************
*** 114,119 ****
--- 114,121 ----
  #define SM_DATABASE        64
  /* SM_USER should be the same size as the others.  bjm 2002-06-02 */
  #define SM_USER            32
+ /* We append database name if db_user_namespace true. */
+ #define SM_DATABASE_USER (SM_DATABASE+SM_USER+1) /* +1 for @ */
  #define SM_OPTIONS        64
  #define SM_UNUSED        64
  #define SM_TTY            64
***************
*** 124,135 ****
--- 126,139 ----
  {
      ProtocolVersion protoVersion;        /* Protocol version */
      char        database[SM_DATABASE];    /* Database name */
+                 /* Db_user_namespace appends dbname */
      char        user[SM_USER];    /* User name */
      char        options[SM_OPTIONS];    /* Optional additional args */
      char        unused[SM_UNUSED];        /* Unused */
      char        tty[SM_TTY];    /* Tty for debug output */
  } StartupPacket;

+ extern bool Db_user_namespace;

  /* These are the authentication requests sent by the backend. */

Re: Open 7.3 items

From

Rod Taylor

Date:

15 August 2002, 17:10:23

> 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.

Re: Open 7.3 items

From

Vince Vielhaber

Date:

15 August 2002, 17:30:40

On Thu, 15 Aug 2002, Tom Lane wrote:

> Vince Vielhaber <vev@michvhf.com> writes:
> > But it doesn't need to affect anyone, even if it's enabled.  Isn't
> > the lack of an @ just as good as an @ at the end of the username?
>
> No, because there isn't any @ in the incoming connection request in the
> normal-user case: just a user name and a database name, which *we* have
> to assemble into user@database.
>
> We can't really expect the users to do this for us (give user@database
> as their full user name).  There are a number of reasons why I don't
> wanna do that, but the real showstopper is that the username field of
> the connection request packet is only 32 bytes wide, and we cannot
> enlarge it without a protocol breakage.  Fitting "user@database" in 32
> bytes would be awfully restrictive about your user and database names.

Ok, I misunderstood.  I thought it was the user going to have to type
that in based on some of yesterday's comments.

Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH    email: vev@michvhf.com    http://www.pop4.net        56K Nationwide Dialup from $16.00/mo
atPop4 Networking     http://www.camping-usa.com      http://www.cloudninegifts.com  http://www.meanstreamradio.com
 http://www.unknown-artists.com
 
==========================================================================

Re: Open 7.3 items

From

Peter Eisentraut

Date:

15 August 2002, 18:27:09

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

Re: Open 7.3 items

From

Tom Lane

Date:

15 August 2002, 18:52:10

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

Re: Open 7.3 items

From

Vince Vielhaber

Date:

15 August 2002, 19:04:38

On Thu, 15 Aug 2002, Tom Lane wrote:

> Peter Eisentraut <peter_e@gmx.net> writes:
> > I don't see what the problem is of dumping out the entire content of
> > pg_shadow into a flat file.  First you look for a non-@ user, then you
> > look for an @ user that matches the database.
>
> While I'd prefer that approach myself, the way Bruce is proposing does
> have a definite advantage: there is no problem with confusion between
> global users and database-local users of the same username.  "foo@" is
> global, "foo" is not.
>
> My own feeling is that the confusion argument is a weak one, and that
> not having to use "@" to log in as a global user would be worth having
> to avoid duplicating global and local names.  But I'm not sufficiently
> excited about it to volunteer to do the work ;-)

Here we go again.  I thought you just said that the @ wouldn't be
something a user would have to do.  I understood that to be any user.
It's back to ugly again.

Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH    email: vev@michvhf.com    http://www.pop4.net        56K Nationwide Dialup from $16.00/mo
atPop4 Networking     http://www.camping-usa.com      http://www.cloudninegifts.com  http://www.meanstreamradio.com
 http://www.unknown-artists.com
 
==========================================================================

Re: Open 7.3 items

From

ngpg@grymmjack.com

Date:

15 August 2002, 22:03:24

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?

Re: Open 7.3 items

From

Bruce Momjian

Date:

16 August 2002, 00:12:28

Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > I don't see what the problem is of dumping out the entire content of
> > pg_shadow into a flat file.  First you look for a non-@ user, then you
> > look for an @ user that matches the database.
> 
> While I'd prefer that approach myself, the way Bruce is proposing does
> have a definite advantage: there is no problem with confusion between
> global users and database-local users of the same username.  "foo@" is
> global, "foo" is not.
> 
> My own feeling is that the confusion argument is a weak one, and that
> not having to use "@" to log in as a global user would be worth having
> to avoid duplicating global and local names.  But I'm not sufficiently
> excited about it to volunteer to do the work ;-)

If we don't suffix global users with '@', a global user named 'dave'
could not attach to a database called 'db1' as himself if a user called
'dave@db1' existed. If you have a super-user, who you want to be able to
connect to any database, the creation of that name in any database would
block the superuser from connecting as themselves.  That is the
confusion I want to avoid.  

I have seen some negative reactions to the feature.  I am willing to ask
for a vote, if that is what people want.  If not, I will apply the patch
in the next day or two.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073

Re: Open 7.3 items

From

Rod Taylor

Date:

16 August 2002, 00:14:38

> I have seen some negative reactions to the feature.  I am willing to ask
> for a vote, if that is what people want.  If not, I will apply the patch
> in the next day or two.

Please apply.

Re: Open 7.3 items

From

Tom Lane

Date:

16 August 2002, 01:20:24

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

Re: Open 7.3 items

From

Bruce Momjian

Date:

16 August 2002, 03:11:04

Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > If we don't suffix global users with '@', a global user named 'dave'
> > could not attach to a database called 'db1' as himself if a user called
> > 'dave@db1' existed.
> 
> No, it's the other way around (assuming you check user before user@db):
> the existence of a global user would prevent similarly-named local users
> from connecting.  This does not strike me as too terrible, assuming that
> there are not very many global users.

Yes, something like that.  It could go either way.  I never actually
coded the double checking.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073

Re: Open 7.3 items

From

Vince Vielhaber

Date:

16 August 2002, 08:21:48

On Thu, 15 Aug 2002, Bruce Momjian wrote:

> I have seen some negative reactions to the feature.  I am willing to ask
> for a vote, if that is what people want.  If not, I will apply the patch
> in the next day or two.

So are you calling for a vote or just willing to ask for one?  I vote for
putting it in contrib and letting whoever wants it apply it and use it.
The more we discuss it the worse it looks.

Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH    email: vev@michvhf.com    http://www.pop4.net        56K Nationwide Dialup from $16.00/mo
atPop4 Networking     http://www.camping-usa.com      http://www.cloudninegifts.com  http://www.meanstreamradio.com
 http://www.unknown-artists.com
 
==========================================================================

Re: Open 7.3 items

From

Tom Lane

Date:

16 August 2002, 12:48:02

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

Re: Open 7.3 items

From

Vince Vielhaber

Date:

16 August 2002, 13:21:14

On Fri, 16 Aug 2002, Tom Lane wrote:

> Vince Vielhaber <vev@michvhf.com> writes:
> > So are you calling for a vote or just willing to ask for one?  I vote for
> > putting it in contrib and letting whoever wants it apply it and use it.
>
> The trouble with putting it in contrib is that that makes it effectively
> unavailable to anyone who installs from RPMs, or otherwise doesn't build
> from source for themselves.  Putting a patch diff in contrib is a bad
> idea anyway since the patch will suffer bit-rot in no time, as the
> referenced files change.

RPMs aren't a good enough reason to put it in.  All features aren't
installed in an RPM, why would this need to?   Besides, anything that
is runtime configurable can end up getting its default changed on a
whim.  Then again as long as 7.2.1 is stable enough for me there's
no reason to upgrade 'cuze I damn sure ain't going back and changing
all sorts of programs and scripts that have global users.

Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH    email: vev@michvhf.com    http://www.pop4.net        56K Nationwide Dialup from $16.00/mo
atPop4 Networking     http://www.camping-usa.com      http://www.cloudninegifts.com  http://www.meanstreamradio.com
 http://www.unknown-artists.com

==========================================================================

Re: Open 7.3 items

From

Lee Kindness

Date:

16 August 2002, 13:40:30

Vince Vielhaber writes:> [ 'user@' patch ]> whim.  Then again as long as 7.2.1 is stable enough for me there's> no
reasonto upgrade 'cuze I damn sure ain't going back and changing> all sorts of programs and scripts that have global
users.

Having read bits and pieces of this thread, can those in favour
confirm that this would be an effect of this patch? If so I fail to
see the usefulness of this and indeed it would be very harmful to
existing installations! All use of PostgreSQL utilities in scripts for
our product always do a '-U sprint' to use a global user, this aids
our internal development and makes installation notes for clients
easier...

Also what effect would adding significance to '@' in the context of
usernames have, if any, on the current use of it as a database/host
separator (in ECPG, certainly would be useful in the utilities too)?

Thanks, Lee.

Re: Open 7.3 items

From

Tom Lane

Date:

16 August 2002, 13:48:48

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

Re: Open 7.3 items

From

"Ross J. Reedstrom"

Date:

16 August 2002, 13:51:14

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

Re: Open 7.3 items

From

Larry Rosenman

Date:

16 August 2002, 14:09:44

On Fri, 2002-08-16 at 09:51, Ross J. Reedstrom wrote:
> On Fri, Aug 16, 2002 at 10:21:12AM -0400, Vince Vielhaber wrote:
>  
> > RPMs aren't a good enough reason to put it in.  All features aren't
> > installed in an RPM, why would this need to?   Besides, anything that
> > is runtime configurable can end up getting its default changed on a
> > whim.  Then again as long as 7.2.1 is stable enough for me there's
> > no reason to upgrade 'cuze I damn sure ain't going back and changing
> > all sorts of programs and scripts that have global users.
>  
> So, Vince, do you have problems with the various GUC based optimizer
> hooks getting set to other than the default? I'd think you'd notice 
> if suddenly indexscans all went away, or any of these:
> 
> #enable_seqscan = true
> #enable_indexscan = true
> #enable_tidscan = true
> #enable_sort = true
> #enable_nestloop = true
> #enable_mergejoin = true
> #enable_hashjoin = true
> 
> My point is that your resistance to a GUC controlled runtime configurable
> on the basis of 'it might get changed accidently' makes little sense to
> me, given all the other runtime config settings that never do get changed.
> What makes you think this one will be more susceptible to accidental
> flipping?
> 
> I'm not sure who's 'whim' it is that your afraid of: perhaps you have a
> paticularly sadistic DBA to deal with? ;-) And of course, this being 
> free software and all, noone is forcing an upgrade on you.
AND, I thought the general consensus was **AWAY** from configure time
directives and to GUC variables whenever **POSSIBLE**. 

LER
-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 972-414-9812                 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

Re: Open 7.3 items

From

Bruce Momjian

Date:

16 August 2002, 14:45:45

Vince Vielhaber wrote:
> On Thu, 15 Aug 2002, Bruce Momjian wrote:
> 
> > I have seen some negative reactions to the feature.  I am willing to ask
> > for a vote, if that is what people want.  If not, I will apply the patch
> > in the next day or two.
> 
> So are you calling for a vote or just willing to ask for one?  I vote for
> putting it in contrib and letting whoever wants it apply it and use it.
> The more we discuss it the worse it looks.

I can do a vote.  However, seeing many positive comments about the
patch, and 1-2 negative ones (with no suggestion on how to improve it),
I don't think the negative votes will win.

I usually do a vote when the email comments are coming in kind of close.

Specifically, in the thread, I have Vince and Peter as negative, and >7
positive, I think.

Look at the contraints I am under to implement what is effectively
username schemas:
small patch, no bloat, because it isn't a core featuremultiple global usersno namespace collisions between
global/non-globaluserszero performance impact32-byte user string coming from the client

Specifically, what is ugly about it?  Is it that global users have an @
at the end of their names?  How do we prevent namespace collisions
_without_ doing this?  I am all ears.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073

Re: Open 7.3 items

From

Tom Lane

Date:

16 August 2002, 15:46:49

Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Specifically, what is ugly about it?  Is it that global users have an @
> at the end of their names?  How do we prevent namespace collisions
> _without_ doing this?  I am all ears.

The folks who are unhappy about this design basically think that the
namespace collisions issue should not be considered a vital requirement;
whereupon you don't have to have the '@' because a search in the
pg_shadow flat file would work well enough.

It comes down to a judgment call about which is uglier, putting '@' on
global usernames or having to avoid namespace collisions.

At this point I think we've wasted more than enough time on the
argument; I haven't seen any new ideas recently, nor any change in
anyone's position.  Since no one seems to want to do the work to make a
better implementation, I vote we accept the patch we have and move on.
        regards, tom lane

Re: Open 7.3 items

From

Vince Vielhaber

Date:

16 August 2002, 16:06:24

On Fri, 16 Aug 2002, Tom Lane wrote:

> Lee Kindness <lkindness@csl.co.uk> writes:
> > Vince Vielhaber writes:
> >>> [ 'user@' patch ]
> >>> whim.  Then again as long as 7.2.1 is stable enough for me there's
> >>> no reason to upgrade 'cuze I damn sure ain't going back and changing
> >>> all sorts of programs and scripts that have global users.
>
> > Having read bits and pieces of this thread, can those in favour
> > confirm that this would be an effect of this patch?
>
> I think Vince is talking through his hat.  The proposed flag wouldn't
> ever be enabled by default.  If someone did turn it on in their
> installation "on a whim", they'd soon turn it off again if they didn't
> like the effects.  I do not see much difference between the above
> argument and arguing "we shouldn't have i18n support, because if I
> turned it on on a whim I wouldn't be able to read my error messages".
>
> Once again: *no one* has at any time suggested that any form of this
> patch should affect the default behavior in the slightest.

Not yet they haven't.  What happens when it's decided that this
*feature* is a good thing and should be the default?   Maybe not
now, but can you guarantee that that won't happen in say 7.4?  Or
maybe 8.0?  I can hear it now, "Well we're giving you an entire
version to change your scripts".

There's not even a concensus that this is the right way to do it,
you even said you'd prefer it was implemented in another way but
don't have the time to do it.  Since when does this group rush to
stuff features in without agreement even on HOW to implement it?

Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH    email: vev@michvhf.com    http://www.pop4.net        56K Nationwide Dialup from $16.00/mo
atPop4 Networking     http://www.camping-usa.com      http://www.cloudninegifts.com  http://www.meanstreamradio.com
 http://www.unknown-artists.com
 
==========================================================================

Re: Open 7.3 items

From

Bruce Momjian

Date:

16 August 2002, 16:30:25

Vince Vielhaber wrote:
> > Once again: *no one* has at any time suggested that any form of this
> > patch should affect the default behavior in the slightest.
> 
> Not yet they haven't.  What happens when it's decided that this
> *feature* is a good thing and should be the default?   Maybe not
> now, but can you guarantee that that won't happen in say 7.4?  Or
> maybe 8.0?  I can hear it now, "Well we're giving you an entire
> version to change your scripts".

I can't argue hypothetical with you, but if we decided to make this a
default behavior, we would probably push the functionality down into
CREATE USER, create a new column in pg_shadow, lengthen the username
passed from the client, and do it that way.  However, because it is not
on by default _and_ we don't want to add visibility to a functionality
that is off by default, we are doing it this way.

Remember, non-local users already have an @ in their username.  I am
just adding @ to the global users too. This functionality actually
allows you to keep your old users in pg_shadow and once you turn on the
feature, those users become unusable.  When you turn the feature off,
they are back again.

I know the trailing @ is ugly, but it prevents surpises when connecting
to the database.

> There's not even a consensus that this is the right way to do it,
> you even said you'd prefer it was implemented in another way but
> don't have the time to do it.  Since when does this group rush to
> stuff features in without agreement even on HOW to implement it?

This is an argument I don't want to bow to.  How many features have we
left undone, for release after release, because we couldn't find a
perfect way to do it, so we did nothing, and users went elsewhere for
their database needs?   We have had enough discussion to know that there
isn't a perfect solution in this case, so we are going to implement the
best we can, and if we have to revisit it in 8.0, so be it.  I am sure
you will still be around to help craft that solution.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073

Re: Open 7.3 items

From

Vince Vielhaber

Date:

16 August 2002, 16:34:12

On Fri, 16 Aug 2002, Ross J. Reedstrom wrote:

> On Fri, Aug 16, 2002 at 10:21:12AM -0400, Vince Vielhaber wrote:
>
> > RPMs aren't a good enough reason to put it in.  All features aren't
> > installed in an RPM, why would this need to?   Besides, anything that
> > is runtime configurable can end up getting its default changed on a
> > whim.  Then again as long as 7.2.1 is stable enough for me there's
> > no reason to upgrade 'cuze I damn sure ain't going back and changing
> > all sorts of programs and scripts that have global users.
>
> So, Vince, do you have problems with the various GUC based optimizer
> hooks getting set to other than the default? I'd think you'd notice
> if suddenly indexscans all went away, or any of these:
>
> #enable_seqscan = true
> #enable_indexscan = true
> #enable_tidscan = true
> #enable_sort = true
> #enable_nestloop = true
> #enable_mergejoin = true
> #enable_hashjoin = true
>
> My point is that your resistance to a GUC controlled runtime configurable
> on the basis of 'it might get changed accidently' makes little sense to
> me, given all the other runtime config settings that never do get changed.
> What makes you think this one will be more susceptible to accidental
> flipping?

My point has nothing to do with resistance to GUC configurables.  Someone
WILL decide that having it as a default is a *Good Thing* because it's
there and is useful to them and in its current implementation there's not
even a concensus that it's the right way to do it.  It's being rushed into
this version unnecessarily.

Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH    email: vev@michvhf.com    http://www.pop4.net        56K Nationwide Dialup from $16.00/mo
atPop4 Networking     http://www.camping-usa.com      http://www.cloudninegifts.com  http://www.meanstreamradio.com
 http://www.unknown-artists.com
 
==========================================================================

Re: Open 7.3 items

From

Tom Lane

Date:

16 August 2002, 17:18:00

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

Re: Open 7.3 items

From

Tom Lane

Date:

16 August 2002, 17:29:28

BTW, I just thought of a small improvement to your patch that eliminates
some of the ugliness.  Suppose that when we recognize an attempt to
connect as a global user (ie, feature flag is on and last character of
username is '@'), we strip off the '@' before proceeding.  Then we would
have:global users appear in pg_shadow as foolocal users appear in pg_shadow as foo@db
and what this would mean is that you can flip between feature-enabled
and feature-disabled states without breaking your global logins.  So you
don't need the extra step of creating a "postgres@" before turning on
the feature.  (Which was pretty ugly anyway, since even though postgres@
could be made a superuser, he wouldn't be the same user as postgres ---
this affects table ownership, for example, and would be a serious issue
if you wanted any non-superuser global users.)

I suppose some might argue that having to say postgres@ to log in,
when your username is really just postgres as far as you can see in the
database, is a tad confusing.  But the whole thing is an acknowledged
wart anyway, and I think getting rid of the two problems mentioned above
is worth it.

Also, if we do this then it's important to strip a trailing '@' only
if it's the *only* one in the given username.  Else a local user
'foo@db1' could cheat to log into db2 by saying username = 'foo@db1@'
with requested database db2.  But I can't see any other security hole.
        regards, tom lane

Re: Open 7.3 items

From

Bruce Momjian

Date:

16 August 2002, 18:03:27

Tom Lane wrote:
> BTW, I just thought of a small improvement to your patch that eliminates
> some of the ugliness.  Suppose that when we recognize an attempt to
> connect as a global user (ie, feature flag is on and last character of
> username is '@'), we strip off the '@' before proceeding.  Then we would
> have:
>     global users appear in pg_shadow as foo
>     local users appear in pg_shadow as foo@db
> and what this would mean is that you can flip between feature-enabled
> and feature-disabled states without breaking your global logins.  So you
> don't need the extra step of creating a "postgres@" before turning on
> the feature.  (Which was pretty ugly anyway, since even though postgres@
> could be made a superuser, he wouldn't be the same user as postgres ---
> this affects table ownership, for example, and would be a serious issue
> if you wanted any non-superuser global users.)
> 
> I suppose some might argue that having to say postgres@ to log in,
> when your username is really just postgres as far as you can see in the
> database, is a tad confusing.  But the whole thing is an acknowledged
> wart anyway, and I think getting rid of the two problems mentioned above
> is worth it.

Sure. If I can get one more 'yes' I will submit a new patch with the
change.  It does prevent the namespace collision without mucking up
pg_shadow.  We only need to tell people that global users need to supply
their username to the client as user@.  Is that cleaner?

> Also, if we do this then it's important to strip a trailing '@' only
> if it's the *only* one in the given username.  Else a local user
> 'foo@db1' could cheat to log into db2 by saying username = 'foo@db1@'
> with requested database db2.  But I can't see any other security hole.

Ewe, I didn't think of that.  Good point.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073

Re: Open 7.3 items

From

Oliver Elphick

Date:

16 August 2002, 18:31:05

On Fri, 2002-08-16 at 20:03, Bruce Momjian wrote:
> Sure. If I can get one more 'yes' I will submit a new patch with the
> change.  It does prevent the namespace collision without mucking up
> pg_shadow.  We only need to tell people that global users need to supply
> their username to the client as user@.  Is that cleaner?

I will vote yes for this change.  I think the flexibility this new
system offers will make it much easier for people to offer PostgreSQL
hosting facilities, of which I would like to see many more.

-- 
Oliver Elphick                                Oliver.Elphick@lfix.co.uk
Isle of Wight, UK                            
http://www.lfix.co.uk/oliver
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839  932A 614D 4C34 3E1D 0C1C
========================================   "And whatsoever ye shall ask in my name, that will I      do, that the
Fathermay be glorified in the Son."                                              John 14:13

Re: Open 7.3 items

From

ngpg@grymmjack.com

Date:

16 August 2002, 23:40:35

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..

Re: Open 7.3 items

From

Bruce Momjian

Date:

17 August 2002, 01:13:06

ngpg@grymmjack.com wrote:
> pgman@candle.pha.pa.us (Bruce Momjian) wrote
> > 
> > I know the trailing @ is ugly, but it prevents surpises when connecting
> > to the database.
> > 
> 
> if you would make the magic character a variable then perhaps you could 
> prevent the ugly...  if/when you turn off the feature, you could set the 
> PGSQL_STUPID_MAGIC_CHARACTER to '', then you would be appending an empty 
> string instead of a @, when you want to turn it back on, set the variable 
> back to '@'... and if you change the character, well dont..

It already does that.  When it is off, it works just like it does in 7.2.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073

Re: Open 7.3 items

From

Bruce Momjian

Date:

17 August 2002, 03:16:20

OK, here is the patch with the suggested changes.  I am sending the
patch to hackers because there has been so much interest in this.

---------------------------------------------------------------------------

Tom Lane wrote:
> BTW, I just thought of a small improvement to your patch that eliminates
> some of the ugliness.  Suppose that when we recognize an attempt to
> connect as a global user (ie, feature flag is on and last character of
> username is '@'), we strip off the '@' before proceeding.  Then we would
> have:
>     global users appear in pg_shadow as foo
>     local users appear in pg_shadow as foo@db
> and what this would mean is that you can flip between feature-enabled
> and feature-disabled states without breaking your global logins.  So you
> don't need the extra step of creating a "postgres@" before turning on
> the feature.  (Which was pretty ugly anyway, since even though postgres@
> could be made a superuser, he wouldn't be the same user as postgres ---
> this affects table ownership, for example, and would be a serious issue
> if you wanted any non-superuser global users.)
>
> I suppose some might argue that having to say postgres@ to log in,
> when your username is really just postgres as far as you can see in the
> database, is a tad confusing.  But the whole thing is an acknowledged
> wart anyway, and I think getting rid of the two problems mentioned above
> is worth it.
>
> Also, if we do this then it's important to strip a trailing '@' only
> if it's the *only* one in the given username.  Else a local user
> 'foo@db1' could cheat to log into db2 by saying username = 'foo@db1@'
> with requested database db2.  But I can't see any other security hole.
>
>             regards, tom lane
>

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073
Index: doc/src/sgml/runtime.sgml
===================================================================
RCS file: /cvsroot/pgsql-server/doc/src/sgml/runtime.sgml,v
retrieving revision 1.125
diff -c -r1.125 runtime.sgml
*** doc/src/sgml/runtime.sgml    15 Aug 2002 14:26:15 -0000    1.125
--- doc/src/sgml/runtime.sgml    17 Aug 2002 04:14:34 -0000
***************
*** 1191,1196 ****
--- 1191,1216 ----
       </varlistentry>

       <varlistentry>
+       <term><varname>DB_USER_NAMESPACE</varname> (<type>boolean</type>)</term>
+       <listitem>
+        <para>
+         This allows per-database user names.  You can create users as <literal>
+         username@dbname</>.  When <literal>username</> is passed by the client,
+         <literal>@</> and the database name is appended to the user name and
+         that database-specific user name is looked up by the server.
+         When creating user names containing <literal>@</>, you will need
+         to quote the user name.
+        </para>
+        <para>
+         With this option enabled, you can still create ordinary global
+         users.  Simply append <literal>@</> when specifying the user name
+         in the client.  The <literal>@</> will be stripped off and looked up
+         by the server.
+        </para>
+       </listitem>
+      </varlistentry>
+
+      <varlistentry>
        <indexterm>
         <primary>deadlock</primary>
         <secondary>timeout</secondary>
Index: src/backend/libpq/auth.c
===================================================================
RCS file: /cvsroot/pgsql-server/src/backend/libpq/auth.c,v
retrieving revision 1.82
diff -c -r1.82 auth.c
*** src/backend/libpq/auth.c    20 Jun 2002 20:29:28 -0000    1.82
--- src/backend/libpq/auth.c    17 Aug 2002 04:14:35 -0000
***************
*** 117,123 ****
               version, PG_KRB4_VERSION);
          return STATUS_ERROR;
      }
!     if (strncmp(port->user, auth_data.pname, SM_USER) != 0)
      {
          elog(LOG, "pg_krb4_recvauth: name \"%s\" != \"%s\"",
               port->user, auth_data.pname);
--- 117,123 ----
               version, PG_KRB4_VERSION);
          return STATUS_ERROR;
      }
!     if (strncmp(port->user, auth_data.pname, SM_DATABASE_USER) != 0)
      {
          elog(LOG, "pg_krb4_recvauth: name \"%s\" != \"%s\"",
               port->user, auth_data.pname);
***************
*** 290,296 ****
      }

      kusername = pg_an_to_ln(kusername);
!     if (strncmp(port->user, kusername, SM_USER))
      {
          elog(LOG, "pg_krb5_recvauth: user name \"%s\" != krb5 name \"%s\"",
               port->user, kusername);
--- 290,296 ----
      }

      kusername = pg_an_to_ln(kusername);
!     if (strncmp(port->user, kusername, SM_DATABASE_USER))
      {
          elog(LOG, "pg_krb5_recvauth: user name \"%s\" != krb5 name \"%s\"",
               port->user, kusername);
Index: src/backend/postmaster/postmaster.c
===================================================================
RCS file: /cvsroot/pgsql-server/src/backend/postmaster/postmaster.c,v
retrieving revision 1.283
diff -c -r1.283 postmaster.c
*** src/backend/postmaster/postmaster.c    10 Aug 2002 20:29:18 -0000    1.283
--- src/backend/postmaster/postmaster.c    17 Aug 2002 04:14:40 -0000
***************
*** 116,122 ****
  sigset_t    UnBlockSig,
              BlockSig,
              AuthBlockSig;
-
  #else
  int            UnBlockSig,
              BlockSig,
--- 116,121 ----
***************
*** 191,196 ****
--- 190,197 ----
  bool        HostnameLookup;        /* for ps display */
  bool        ShowPortNumber;
  bool        Log_connections = false;
+ bool        Db_user_namespace = false;
+

  /* Startup/shutdown state */
  static pid_t StartupPID = 0,
***************
*** 1161,1166 ****
--- 1162,1182 ----
      if (port->user[0] == '\0')
          elog(FATAL, "no PostgreSQL user name specified in startup packet");

+     if (Db_user_namespace)
+     {
+         /* If user@, it is a global user, remove '@' */
+         if (strchr(port->user, '@') == port->user + strlen(port->user)-1)
+             *strchr(port->user, '@') = '\0';
+         else
+         {
+             /* Append '@' and dbname */
+             char hold_user[SM_DATABASE_USER+1];
+             snprintf(hold_user, SM_DATABASE_USER+1, "%s@%s", port->user,
+                      port->database);
+             strcpy(port->user, hold_user);
+         }
+     }
+
      /*
       * If we're going to reject the connection due to database state, say
       * so now instead of wasting cycles on an authentication exchange.
***************
*** 2587,2597 ****
      if (FindExec(fullprogname, argv[0], "postmaster") < 0)
          return false;

!     filename = palloc(strlen(DataDir) + 20);
      sprintf(filename, "%s/postmaster.opts", DataDir);

!     fp = fopen(filename, "w");
!     if (fp == NULL)
      {
          postmaster_error("cannot create file %s: %s",
                           filename, strerror(errno));
--- 2603,2612 ----
      if (FindExec(fullprogname, argv[0], "postmaster") < 0)
          return false;

!     filename = palloc(strlen(DataDir) + 17);
      sprintf(filename, "%s/postmaster.opts", DataDir);

!     if ((fp = fopen(filename, "w")) == NULL)
      {
          postmaster_error("cannot create file %s: %s",
                           filename, strerror(errno));
Index: src/backend/utils/misc/guc.c
===================================================================
RCS file: /cvsroot/pgsql-server/src/backend/utils/misc/guc.c,v
retrieving revision 1.82
diff -c -r1.82 guc.c
*** src/backend/utils/misc/guc.c    15 Aug 2002 02:51:26 -0000    1.82
--- src/backend/utils/misc/guc.c    17 Aug 2002 04:14:49 -0000
***************
*** 483,488 ****
--- 483,492 ----
          { "transform_null_equals", PGC_USERSET }, &Transform_null_equals,
          false, NULL, NULL
      },
+     {
+         { "db_user_namespace", PGC_SIGHUP }, &Db_user_namespace,
+         false, NULL, NULL
+     },

      {
          { NULL, 0 }, NULL, false, NULL, NULL
Index: src/backend/utils/misc/postgresql.conf.sample
===================================================================
RCS file: /cvsroot/pgsql-server/src/backend/utils/misc/postgresql.conf.sample,v
retrieving revision 1.44
diff -c -r1.44 postgresql.conf.sample
*** src/backend/utils/misc/postgresql.conf.sample    12 Aug 2002 00:36:12 -0000    1.44
--- src/backend/utils/misc/postgresql.conf.sample    17 Aug 2002 04:14:50 -0000
***************
*** 113,119 ****
  #
  #    Message display
  #
-
  #server_min_messages = notice    # Values, in order of decreasing detail:
                  #   debug5, debug4, debug3, debug2, debug1,
                  #   info, notice, warning, error, log, fatal,
--- 113,118 ----
***************
*** 201,203 ****
--- 200,203 ----
  #sql_inheritance = true
  #transform_null_equals = false
  #statement_timeout = 0                # 0 is disabled
+ #db_user_namespace = false
Index: src/include/libpq/libpq-be.h
===================================================================
RCS file: /cvsroot/pgsql-server/src/include/libpq/libpq-be.h,v
retrieving revision 1.32
diff -c -r1.32 libpq-be.h
*** src/include/libpq/libpq-be.h    20 Jun 2002 20:29:49 -0000    1.32
--- src/include/libpq/libpq-be.h    17 Aug 2002 04:14:50 -0000
***************
*** 59,65 ****

      ProtocolVersion proto;
      char        database[SM_DATABASE + 1];
!     char        user[SM_USER + 1];
      char        options[SM_OPTIONS + 1];
      char        tty[SM_TTY + 1];
      char        auth_arg[MAX_AUTH_ARG];
--- 59,65 ----

      ProtocolVersion proto;
      char        database[SM_DATABASE + 1];
!     char        user[SM_DATABASE_USER + 1];
      char        options[SM_OPTIONS + 1];
      char        tty[SM_TTY + 1];
      char        auth_arg[MAX_AUTH_ARG];
Index: src/include/libpq/pqcomm.h
===================================================================
RCS file: /cvsroot/pgsql-server/src/include/libpq/pqcomm.h,v
retrieving revision 1.65
diff -c -r1.65 pqcomm.h
*** src/include/libpq/pqcomm.h    12 Aug 2002 14:35:26 -0000    1.65
--- src/include/libpq/pqcomm.h    17 Aug 2002 04:14:50 -0000
***************
*** 114,119 ****
--- 114,121 ----
  #define SM_DATABASE        64
  /* SM_USER should be the same size as the others.  bjm 2002-06-02 */
  #define SM_USER            32
+ /* We append database name if db_user_namespace true. */
+ #define SM_DATABASE_USER (SM_DATABASE+SM_USER+1) /* +1 for @ */
  #define SM_OPTIONS        64
  #define SM_UNUSED        64
  #define SM_TTY            64
***************
*** 124,135 ****
--- 126,139 ----
  {
      ProtocolVersion protoVersion;        /* Protocol version */
      char        database[SM_DATABASE];    /* Database name */
+                 /* Db_user_namespace appends dbname */
      char        user[SM_USER];    /* User name */
      char        options[SM_OPTIONS];    /* Optional additional args */
      char        unused[SM_UNUSED];        /* Unused */
      char        tty[SM_TTY];    /* Tty for debug output */
  } StartupPacket;

+ extern bool Db_user_namespace;

  /* These are the authentication requests sent by the backend. */

Re: Open 7.3 items

From

Bruce Momjian

Date:

17 August 2002, 03:17:16

Sample run:$ psql -U postgres testpsql: FATAL:  user "postgres@test" does not exist
$ psql -U postgres@ testWelcome to psql 7.3devel, the PostgreSQL interactive terminal.Type:  \copyright for
distributionterms       \h for help with SQL commands       \? for help on internal slash commands       \g or
terminatewith semicolon to execute query       \q to quittest=> 
 

---------------------------------------------------------------------------

Tom Lane wrote:
> BTW, I just thought of a small improvement to your patch that eliminates
> some of the ugliness.  Suppose that when we recognize an attempt to
> connect as a global user (ie, feature flag is on and last character of
> username is '@'), we strip off the '@' before proceeding.  Then we would
> have:
>     global users appear in pg_shadow as foo
>     local users appear in pg_shadow as foo@db
> and what this would mean is that you can flip between feature-enabled
> and feature-disabled states without breaking your global logins.  So you
> don't need the extra step of creating a "postgres@" before turning on
> the feature.  (Which was pretty ugly anyway, since even though postgres@
> could be made a superuser, he wouldn't be the same user as postgres ---
> this affects table ownership, for example, and would be a serious issue
> if you wanted any non-superuser global users.)
> 
> I suppose some might argue that having to say postgres@ to log in,
> when your username is really just postgres as far as you can see in the
> database, is a tad confusing.  But the whole thing is an acknowledged
> wart anyway, and I think getting rid of the two problems mentioned above
> is worth it.
> 
> Also, if we do this then it's important to strip a trailing '@' only
> if it's the *only* one in the given username.  Else a local user
> 'foo@db1' could cheat to log into db2 by saying username = 'foo@db1@'
> with requested database db2.  But I can't see any other security hole.
> 
>             regards, tom lane
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073

Re: Open 7.3 items

From

Bruce Momjian

Date:

17 August 2002, 15:26:45

OK, I think we are doing this backwards.  Instead of adding '@' to
global users, and then removing it in the backend, why don't we have
local users end with '@', that way, global users continue to connect
just as they have before, and local users connect with @, so dave@db1
connects as 'dave@' and if he has other database access, he can use the
same 'dave@' name.

That removes some of the uglification, I think.

---------------------------------------------------------------------------

Tom Lane wrote:
> BTW, I just thought of a small improvement to your patch that eliminates
> some of the ugliness.  Suppose that when we recognize an attempt to
> connect as a global user (ie, feature flag is on and last character of
> username is '@'), we strip off the '@' before proceeding.  Then we would
> have:
>     global users appear in pg_shadow as foo
>     local users appear in pg_shadow as foo@db
> and what this would mean is that you can flip between feature-enabled
> and feature-disabled states without breaking your global logins.  So you
> don't need the extra step of creating a "postgres@" before turning on
> the feature.  (Which was pretty ugly anyway, since even though postgres@
> could be made a superuser, he wouldn't be the same user as postgres ---
> this affects table ownership, for example, and would be a serious issue
> if you wanted any non-superuser global users.)
> 
> I suppose some might argue that having to say postgres@ to log in,
> when your username is really just postgres as far as you can see in the
> database, is a tad confusing.  But the whole thing is an acknowledged
> wart anyway, and I think getting rid of the two problems mentioned above
> is worth it.
> 
> Also, if we do this then it's important to strip a trailing '@' only
> if it's the *only* one in the given username.  Else a local user
> 'foo@db1' could cheat to log into db2 by saying username = 'foo@db1@'
> with requested database db2.  But I can't see any other security hole.
> 
>             regards, tom lane
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073

Re: Open 7.3 items

From

Tom Lane

Date:

17 August 2002, 15:47:43

Bruce Momjian <pgman@candle.pha.pa.us> writes:
> OK, I think we are doing this backwards.  Instead of adding '@' to
> global users, and then removing it in the backend, why don't we have
> local users end with '@', that way, global users continue to connect
> just as they have before, and local users connect with @, so dave@db1
> connects as 'dave@' and if he has other database access, he can use the
> same 'dave@' name.

No, *that* would be backwards.  In installations that are using this
feature, the vast majority of the users are going to be local ones.
And the global users will be the presumably-more-sophisticated admins.
Putting the onus of the '@' decoration on the local users instead of
the global ones is exactly the wrong way to go.
        regards, tom lane

Re: Open 7.3 items

From

Bruce Momjian

Date:

17 August 2002, 22:41:19

Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > OK, I think we are doing this backwards.  Instead of adding '@' to
> > global users, and then removing it in the backend, why don't we have
> > local users end with '@', that way, global users continue to connect
> > just as they have before, and local users connect with @, so dave@db1
> > connects as 'dave@' and if he has other database access, he can use the
> > same 'dave@' name.
> 
> No, *that* would be backwards.  In installations that are using this
> feature, the vast majority of the users are going to be local ones.
> And the global users will be the presumably-more-sophisticated admins.
> Putting the onus of the '@' decoration on the local users instead of
> the global ones is exactly the wrong way to go.

OK, but it looks slightly less ugly.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073

Re: Open 7.3 items

From

Tom Lane

Date:

18 August 2002, 01:36:14

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

Re: Open 7.3 items

From

Bruce Momjian

Date:

18 August 2002, 02:04:05

OK, applied, with that change.

---------------------------------------------------------------------------

Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > OK, here is the patch with the suggested changes.  I am sending the
> > patch to hackers because there has been so much interest in this.
> 
> One minor gripe:
> 
> > +         /* If user@, it is a global user, remove '@' */
> > +         if (strchr(port->user, '@') == port->user + strlen(port->user)-1)
> 
> This code is correct, but it tempts someone to replace the strchr()
> with a single-character check on the last character of the string.
> Which would introduce the security hole we discussed before.  The
> code is okay, but *please* improve the comment to point out that you
> are also excluding the case where there are @'s to the left of the
> last character.
> 
>             regards, tom lane
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073

Re: Open 7.3 items

From

Peter Eisentraut

Date:

18 August 2002, 08:33:50

Tom Lane writes:

> BTW, I just thought of a small improvement to your patch that eliminates
> some of the ugliness.  Suppose that when we recognize an attempt to
> connect as a global user (ie, feature flag is on and last character of
> username is '@'), we strip off the '@' before proceeding.

I'm missing how hard it is to change "last character of username is @" to
"no @ in username".  This would seem to be a two-line change somewhere.

I'm concerned that we leave essentially no migration path, that is, the
ability to turn the feature on to try it out without immediately breaking
every application.

-- 
Peter Eisentraut   peter_e@gmx.net

Re: Open 7.3 items

From

Tom Lane

Date:

18 August 2002, 15:55:44

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

Re: Open 7.3 items

From

Vince Vielhaber

Date:

18 August 2002, 16:10:18

On Sat, 17 Aug 2002, Bruce Momjian wrote:

>
> OK, I think we are doing this backwards.  Instead of adding '@' to
> global users, and then removing it in the backend, why don't we have
> local users end with '@', that way, global users continue to connect
> just as they have before, and local users connect with @, so dave@db1
> connects as 'dave@' and if he has other database access, he can use the
> same 'dave@' name.
>
> That removes some of the uglification, I think.

Then why was it when I mentioned global users not having the @ you shot
it down as not possible?

Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH    email: vev@michvhf.com    http://www.pop4.net        56K Nationwide Dialup from $16.00/mo
atPop4 Networking     http://www.camping-usa.com      http://www.cloudninegifts.com  http://www.meanstreamradio.com
 http://www.unknown-artists.com
 
==========================================================================

Re: Open 7.3 items

From

Vince Vielhaber

Date:

18 August 2002, 16:13:25

On Sat, 17 Aug 2002, Tom Lane wrote:

> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > OK, I think we are doing this backwards.  Instead of adding '@' to
> > global users, and then removing it in the backend, why don't we have
> > local users end with '@', that way, global users continue to connect
> > just as they have before, and local users connect with @, so dave@db1
> > connects as 'dave@' and if he has other database access, he can use the
> > same 'dave@' name.
>
> No, *that* would be backwards.  In installations that are using this
> feature, the vast majority of the users are going to be local ones.
> And the global users will be the presumably-more-sophisticated admins.
> Putting the onus of the '@' decoration on the local users instead of
> the global ones is exactly the wrong way to go.

Unsophisticated users is hardly a reason.  After all they do have an
@ in their email address.  If they're told the username is foo@ then
their username is foo@.  What's so difficult about that?

Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH    email: vev@michvhf.com    http://www.pop4.net        56K Nationwide Dialup from $16.00/mo
atPop4 Networking     http://www.camping-usa.com      http://www.cloudninegifts.com  http://www.meanstreamradio.com
 http://www.unknown-artists.com
 
==========================================================================

Re: Open 7.3 items

From

Peter Eisentraut

Date:

18 August 2002, 20:32:25

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

Re: Open 7.3 items

From

Tom Lane

Date:

18 August 2002, 21:08:21

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

assigning to NULL?

From

redmonde@purdue.edu

Date:

18 August 2002, 21:25:48

I'm trying to make postGIS work with pg7.3devel. But a problem is occuring that did not appear in pg7.2. When I
execute:

ALTER TABLE geotest ADD CHECK ( geometrytype(geopoint)='POINT'
OR NULL=geopoint);

I get: "ERROR: copyObject: don't know how to copy node type 506"

But when I execute:

ALTER TABLE geotest ADD CHECK ( geometrytype(geopoint)='POINT');

It works fine, which, due to the error message it seems that it is trying to assign rather to NULL, rather than compare
(elsewhat object needs to be copied in "NULL=geopoint"?). Is this a bug, a change in NULL, or a change in user defined
datatypes?
Thanks;
Eric

Re: assigning to NULL?

From

Tom Lane

Date:

18 August 2002, 21:46:34

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

Re: Open 7.3 items

From

ngpg@grymmjack.com

Date:

18 August 2002, 23:01:06

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.

Re: Open 7.3 items

From

Lee Kindness

Date:

19 August 2002, 07:04:41

I'd have thought that if a matching user couldn't be found in the
specified database then it would default to searching through the
global users? Would be more intuitive...

Lee.

Bruce Momjian writes:> Sample run:>     $ psql -U postgres test>     psql: FATAL:  user "postgres@test" does not exist>
>    $ psql -U postgres@ test>     Welcome to psql 7.3devel, the PostgreSQL interactive terminal.

Re: Open 7.3 items

From

Bruce Momjian

Date:

27 August 2002, 18:19:57

I think we need to resolve this discussion from a week ago.  The current
code is this:
global usernames are stored just like before, e.g. postgreslocal users are stored as user@dbnamewhen connecting, global
usersadd '@' to their nameswhen connecting, local users use just their user name, no @dbname
 

Tom likes this because it is the fewer global users who have to append
the '@'.

Vince and Peter think that it should be local users adding '@' when
connecting because:
they have an @ sign in their name anywayglobal users should be able to connect unchanged

I can foresee a time when we will have longer usernames, and local users
will be able to connect with the full user@dbname, and we can allow
user@ as a shortcut.

In summary, I prefer to change the code to have local users append the
'@'.

Comments?  

It is an easy change and prevents what is a very confusing situation
where we add '@' for users who don't have @, and remove '@' for users
who have it.

---------------------------------------------------------------------------

Peter Eisentraut wrote:
> Tom Lane writes:
> 
> > Peter Eisentraut <peter_e@gmx.net> writes:
> > > I'm concerned that we leave essentially no migration path, that is, the
> > > ability to turn the feature on to try it out without immediately breaking
> > > every application.
> >
> > Uh ... what?  I fail to understand your objection.  AFAICS the only
> > apps that could be "broken" are scripts that have usernames hardwired
> > into them ...
> 
> I'm completely lost between all the proposals about where the @ is going
> to be specified, added, or removed.  What happens on the client side and
> what happens on the server side?
> 
> All I would like to see is that I can turn on this feature and nothing
> changes as long as I don't add any "local users".  Yes, that includes
> hard-wired user names on the client side.  Of course there are various
> degrees of hard-wiring, but what if the ISP admin updates to 7.3 and wants
> to turn on the feature for new clients?  Does he tell all his existing
> clients that they must update their user names?  Possibly, these users got
> their database access with a shell account and don't specify the user name
> at all because it defaults to the OS user name.  Does that continue to
> work?
> 
> -- 
> Peter Eisentraut   peter_e@gmx.net
> 
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073

Re: Open 7.3 items

From

Lamar Owen

Date:

27 August 2002, 18:35:58

On Tuesday 27 August 2002 03:19 pm, Bruce Momjian wrote:
> I think we need to resolve this discussion from a week ago.  The current
> code is this:

I thought it WAS resolved, to do:

>     global usernames are stored just like before, e.g. postgres
>     local users are stored as user@dbname
>     when connecting, global users add '@' to their names
>     when connecting, local users use just their user name, no @dbname

> Tom likes this because it is the fewer global users who have to append
> the '@'.

At least that was my perception of the uneasy consensus reached.

Basically, this tags the @ as magic saying, during the client connect process, 
'I'm GLOBAL, treat me differently'.  Now that I actually understand how this 
is supposed to work, which your four lines above elucidate nicely, I am in 
more agreement than I was that this is the right answer to this issue.
-- 
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Re: Open 7.3 items

From

Bruce Momjian

Date:

27 August 2002, 18:43:14

Lamar Owen wrote:
> On Tuesday 27 August 2002 03:19 pm, Bruce Momjian wrote:
> > I think we need to resolve this discussion from a week ago.  The current
> > code is this:
> 
> I thought it WAS resolved, to do:
> 
> >     global usernames are stored just like before, e.g. postgres
> >     local users are stored as user@dbname
> >     when connecting, global users add '@' to their names
> >     when connecting, local users use just their user name, no @dbname
> 
> > Tom likes this because it is the fewer global users who have to append
> > the '@'.
> 
> At least that was my perception of the uneasy consensus reached.
> 
> Basically, this tags the @ as magic saying, during the client connect process, 
> 'I'm GLOBAL, treat me differently'.  Now that I actually understand how this 
> is supposed to work, which your four lines above elucidate nicely, I am in 
> more agreement than I was that this is the right answer to this issue.

OK, you have now split the vote because we have two for the change, and
two against.  Why do you prefer to tag the globals?  Is it Tom's
argument?  I think it is kind of strange to tag the globals when it is
the locals who have @ in their username, and when they do:
$ psql -U dave testWelcome to psql 7.3devel, the PostgreSQL interactive terminal.Type:  \copyright for distribution
terms      \h for help with SQL commands       \? for help on internal slash commands       \g or terminate with
semicolonto execute query       \q to quittest=> select current_user; current_user -------------- dave@test(1 row)

they will see their full username.

I can go either way.  I am just saying we need to hear from more people
to make sure we are doing this properly.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073

Re: Open 7.3 items

From

Tom Lane

Date:

27 August 2002, 18:47:44

Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I can go either way.  I am just saying we need to hear from more people
> to make sure we are doing this properly.

Likewise.  In particular I'd like to hear from Marc, who after all
is the one who caused us to consider this hack in the first place.
Does it satisfy his requirement?  Is one way or the other preferable
for his actual usage?
        regards, tom lane

Re: Open 7.3 items

From

Lamar Owen

Date:

27 August 2002, 19:05:51

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

Re: Open 7.3 items

From

Rod Taylor

Date:

27 August 2002, 19:11:05

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.

Re: Open 7.3 items

From

Bruce Momjian

Date:

27 August 2002, 19:19:57

Lamar Owen wrote:
> On Tuesday 27 August 2002 03:43 pm, Bruce Momjian wrote:
> > Lamar Owen wrote:
> > > On Tuesday 27 August 2002 03:19 pm, Bruce Momjian wrote:
> > > I thought it WAS resolved, to do:
> 
> > > > Tom likes this because it is the fewer global users who have to append
> > > > the '@'.
> 
> > > At least that was my perception of the uneasy consensus reached.
> 
> > OK, you have now split the vote because we have two for the change, and
> > two against.  Why do you prefer to tag the globals?  Is it Tom's
> > argument?  I think it is kind of strange to tag the globals when it is
> > the locals who have @ in their username, and when they do:
> 
> I agree with what Tom said, and understand why he said it.  And I thought you 
> did, too -- I have apparently misunderstood (again!) the issue.

I try not to interject my opinions into emails where I am asking for
disucsion so people can more clearly see the options and vote
accordingly.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073

Re: Open 7.3 items

From

Bruce Momjian

Date:

27 August 2002, 19:20:51

OK, we have enough votes to keep the existing behavior, unless Marc
appears and says he doesn't like it.  ;-)

Thanks.

---------------------------------------------------------------------------

Rod Taylor wrote:
> It should also be noted that it's easy to get the DBAs to change their
> username in the future when / if the @ hack goes away BUT it will be
> difficult to change the usernames of the hundreds to thousands of
> customer accounts.
> 
> For an upgrade, we'd end up making a script in the upgrade to keep them
> the same (with the @) then have a control panel code in place to suggest
> to the user that they may stop using the @ if they wish <click here>
> type of thing.
> 
> 
> > > > > Tom likes this because it is the fewer global users who have to append
> > > > > the '@'.
> > 
> > > > At least that was my perception of the uneasy consensus reached.
> > 
> > > OK, you have now split the vote because we have two for the change, and
> > > two against.  Why do you prefer to tag the globals?  Is it Tom's
> > > argument?  I think it is kind of strange to tag the globals when it is
> > > the locals who have @ in their username, and when they do:
> 
> > In the case of a virtual hosting postmaster, global users would likely be 
> > DBA's, although they might not be.  These users are going to be the 
> > exception, not the rule -- thus a character to tag their 'exceptional' 
> > nature.
> 
> 
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073

Re: Open 7.3 items

From

Oliver Elphick

Date:

27 August 2002, 20:06:04

On Tue, 2002-08-27 at 21:05, Lamar Owen wrote:
> On Tuesday 27 August 2002 03:43 pm, Bruce Momjian wrote:
> > Lamar Owen wrote:
> > > On Tuesday 27 August 2002 03:19 pm, Bruce Momjian wrote:
> > > I thought it WAS resolved, to do:
> 
> > > > Tom likes this because it is the fewer global users who have to append
> > > > the '@'.
> 
> > > At least that was my perception of the uneasy consensus reached.
> 
> > OK, you have now split the vote because we have two for the change, and
> > two against.  Why do you prefer to tag the globals?  Is it Tom's
> > argument?  I think it is kind of strange to tag the globals when it is
> > the locals who have @ in their username, and when they do:
> 
> I agree with what Tom said, and understand why he said it.  And I thought you 
> did, too -- I have apparently misunderstood (again!) the issue.
> 
> In the local-enabled scheme, ISTM the majority of users will be local users.  
> The goal is transparent virtual databases -- at least that's what I consider 
> the goal.  As far as the user is concerned, the other databases might as well 
> not even exist -- all they are doing is connecting to their database.  Since 
> they have to give the database name as part of the connection, it just makes 
> sense that they should have the closest to default behavior.
> 
> In the case of a virtual hosting postmaster, global users would likely be 
> DBA's, although they might not be.  These users are going to be the 
> exception, not the rule -- thus a character to tag their 'exceptional' 
> nature.
> 
> You may not even want your virtual host local users to realize that there is 
> another user by that name.  Thus, the standard notation is the least 
> intrusive for the very users that need uninstrusive notation.

Has this behaviour been carried through into GRANT and REVOKE?  If the
object is transparency for local users, it should be possible in
database "test" to say "GRANT ... TO fred" and have "fred" understood as
"fred@test".

If that is the case, then I will support the current position.


It follows from the objective of transparency that, when reporting a
user name, local users should be reported without the database suffix,
i.e., "fred" not "fred@test".  Global users should be reported with the
trailing "@".  This should cause no problem, because we have no
cross-database communication; it should be impossible for "george@dummy"
to have any connection with database "test".

-- 
Oliver Elphick                                Oliver.Elphick@lfix.co.uk
Isle of Wight, UK                            
http://www.lfix.co.uk/oliver
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839  932A 614D 4C34 3E1D 0C1C
========================================   "But the end of all things is at hand; be ye therefore      sober, and watch
untoprayer. And above all things      have fervent love among yourselves; for love shall       cover the multitude of
sins."     I Peter 4:7,8

Re: Open 7.3 items

From

Bruce Momjian

Date:

27 August 2002, 20:11:52

Oliver Elphick wrote:
> > I agree with what Tom said, and understand why he said it.  And I thought you 
> > did, too -- I have apparently misunderstood (again!) the issue.
> > 
> > In the local-enabled scheme, ISTM the majority of users will be local users.  
> > The goal is transparent virtual databases -- at least that's what I consider 
> > the goal.  As far as the user is concerned, the other databases might as well 
> > not even exist -- all they are doing is connecting to their database.  Since 
> > they have to give the database name as part of the connection, it just makes 
> > sense that they should have the closest to default behavior.
> > 
> > In the case of a virtual hosting postmaster, global users would likely be 
> > DBA's, although they might not be.  These users are going to be the 
> > exception, not the rule -- thus a character to tag their 'exceptional' 
> > nature.
> > 
> > You may not even want your virtual host local users to realize that there is 
> > another user by that name.  Thus, the standard notation is the least 
> > intrusive for the very users that need uninstrusive notation.
> 
> Has this behaviour been carried through into GRANT and REVOKE?  If the
> object is transparency for local users, it should be possible in
> database "test" to say "GRANT ... TO fred" and have "fred" understood as
> "fred@test".

No changes have been made anywhere except for the username passed by the
client.  All reporting of user names and all administration go by their
full pg_shadow username, so global user dave@ is dave in pg_shadow, and
dave is dave@db1 in pg_shadow.  One goal of this patch was a small
footprint.

> If that is the case, then I will support the current position.
> 
> 
> It follows from the objective of transparency that, when reporting a
> user name, local users should be reported without the database suffix,
> i.e., "fred" not "fred@test".  Global users should be reported with the
> trailing "@".  This should cause no problem, because we have no
> cross-database communication; it should be impossible for "george@dummy"
> to have any connection with database "test".

Nope, none of this is done and I don't think there is a demand to do it.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073

Re: Open 7.3 items

From

Peter Eisentraut

Date:

27 August 2002, 20:32:44

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

Re: Open 7.3 items

From

Oliver Elphick

Date:

27 August 2002, 20:33:45

On Tue, 2002-08-27 at 22:11, Bruce Momjian wrote:
> Oliver Elphick wrote:
> > Has this behaviour been carried through into GRANT and REVOKE?  If the
> > object is transparency for local users, it should be possible in
> > database "test" to say "GRANT ... TO fred" and have "fred" understood as
> > "fred@test".
> 
> No changes have been made anywhere except for the username passed by the
> client.  All reporting of user names and all administration go by their
> full pg_shadow username, so global user dave@ is dave in pg_shadow, and
> dave is dave@db1 in pg_shadow.  One goal of this patch was a small
> footprint.

That is understandable, but it means that there is an inconsistency of
usage for _every_ user.

You connect as "postgres@" and "fred", but for all other purposes -
CREATE USER, GRANT, REVOKE, CURRENT_USER, etc. you will be "postgres"
and "fred@database".  This seems likely to cause users confusion, don't
you think?  It also means that any applications which test usernames
will have to be altered to strip off the "@database".

So it seems to me that you have achieved a small footprint within the
code, but potentially at the cost of a larger impact on users.

-- 
Oliver Elphick                                Oliver.Elphick@lfix.co.uk
Isle of Wight, UK                            
http://www.lfix.co.uk/oliver
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839  932A 614D 4C34 3E1D 0C1C
========================================   "But the end of all things is at hand; be ye therefore      sober, and watch
untoprayer. And above all things      have fervent love among yourselves; for love shall       cover the multitude of
sins."     I Peter 4:7,8

Re: Open 7.3 items

From

Tom Lane

Date:

27 August 2002, 20:45:28

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

Re: Open 7.3 items

From

Tom Lane

Date:

27 August 2002, 20:47:06

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

Re: Open 7.3 items

From

Oliver Elphick

Date:

27 August 2002, 20:58:31

On Tue, 2002-08-27 at 22:44, Tom Lane wrote:
> Oliver Elphick <olly@lfix.co.uk> writes:
> > So it seems to me that you have achieved a small footprint within the
> > code, but potentially at the cost of a larger impact on users.
> 
> I don't think anyone will deny that this is a kluge.  However, we are
> not going to resurrect the separate-password-file thing (that was a
> worse kluge, especially when used for this purpose), and we are not
> going to postpone 7.3 while we think about a nicer solution.  So, simple
> is beautiful for now.  If there are enough people actually *using* this
> feature to make it worth improving, we can improve it ... later.

Could we then have a TODO item:
 * Make local and global user representation consistent throughout.

-- 
Oliver Elphick                                Oliver.Elphick@lfix.co.uk
Isle of Wight, UK                            
http://www.lfix.co.uk/oliver
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839  932A 614D 4C34 3E1D 0C1C
========================================   "But the end of all things is at hand; be ye therefore      sober, and watch
untoprayer. And above all things      have fervent love among yourselves; for love shall       cover the multitude of
sins."     I Peter 4:7,8

Re: Open 7.3 items

From

Tom Lane

Date:

27 August 2002, 21:10:58

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

Re: Open 7.3 items

From

Tom Lane

Date:

27 August 2002, 21:17:34

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

Re: Open 7.3 items

From

Bruce Momjian

Date:

28 August 2002, 00:07:18

Tom Lane wrote:
> Oliver Elphick <olly@lfix.co.uk> writes:
> > Could we then have a TODO item:
> >   * Make local and global user representation consistent throughout.
> 
> That's hardly an appropriately expansive TODO item.  I prefer
> 
>     * Provide a real solution for database-local users

I say let's get it out in the field and see what people ask for.  For
all we know, they may be very happy with this, nor not use it at all.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073

Re: Open 7.3 items

From

Bruce Momjian

Date:

28 August 2002, 00:08:08

Peter Eisentraut wrote:
> Bruce Momjian writes:
> 
> >     global usernames are stored just like before, e.g. postgres
> >     local users are stored as user@dbname
> >     when connecting, global users add '@' to their names
> >     when connecting, local users use just their user name, no @dbname
> 
> I'm OK with this in principle.  But I must say I was quite confused
> because the "@" symbol appears in diametrically opposite contexts:
> 
> a) designate local users on the server
> 
> b) designate global users in the client
> 
> Perhaps I might have been less confused if meaning (b) used a different
> character, say "username!".  This might be equally confusing to the next
> person -- just my observation.

There is no question it is 100% confusing.  You are not alone.

What keeps us from unconfusing it is the desire to make local usernames
clean looking, I think.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073

Re: Open 7.3 items

From

Oliver Elphick

Date:

28 August 2002, 06:22:57

On Tue, 2002-08-27 at 23:10, Tom Lane wrote: 
> Oliver Elphick <olly@lfix.co.uk> writes:
> > This should cause no problem, because we have no
> > cross-database communication; it should be impossible for "george@dummy"
> > to have any connection with database "test".
> 
> Not so; you need look no further than the owner column of pg_database
> to find a case where people can see usernames that might be local to
> other databases.  Group membership lists might well contain users
> from multiple databases, too.

I suspect I have a different view of the ultimate aim of this feature.

If we go to a thorough solution for virtual local databases, local users
of other databases ought to be completely invisible.  I suppose that
means that to a local user, pg_database would be a view showing only
template[01] and the local database. pg_shadow, too, would show only
global users and local users in the same database.

I can't see how a group within a local database could contain users from
other databases.   In the context in which this is being used, each
database belongs to a different customer; each database needs to be
invisible to other customers.  How then should it be possible to have
group lists containing users from different local databases?  Groups
should be local as well as users.

Perhaps I like complicating things too much...

-- 
Oliver Elphick                                Oliver.Elphick@lfix.co.uk
Isle of Wight, UK                            
http://www.lfix.co.uk/oliver
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839  932A 614D 4C34 3E1D 0C1C
========================================   "Use hospitality one to another without grudging."
           I Peter 4:9

Re: Open 7.3 items

From

Tom Lane

Date:

28 August 2002, 12:15:54

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