cvs server: Updating src/backend/utils/mb/conversion_procs/ascii_and_mic
cvs server: failed to create lock directory for
`/projects/cvsroot/pgsql-server/src/backend/utils/mb/conversion_procs/ascii_and_mic'
Summary:
1. The current implementation is broken.
2. We have no proper description of how a fixed implementation
should work.
3. It's hard to fix the current implementation without such a
description.
4. Thus, we are in other messages here trying to work
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?
---(end of
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
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
Hi guys,
The fulltextindex Makefile looks like this:
subdir = contrib/fulltextindex
top_builddir = ../..
include $(top_builddir)/src/Makefile.global
MODULE_big = fti
OBJS = list.o chtbl.o fti.o
DATA_built = fti.sql
DOCS = README.fti
SCRIPTS = fti.pl
include
Damn - I'm getting it too:
P src/backend/utils/fmgr/fmgr.c
P src/backend/utils/mb/conv.c
P src/backend/utils/mb/mbutils.c
P src/backend/utils/mb/conversion_procs/Makefile
cvs server: failed to create lock directory for
`/projects/cvsroot/pgsql-server/src/backend/utils/mb/conversion_procs/ascii_
On Wed, 2002-08-14 at 07:51, Oliver Elphick wrote:
cvs server: Updating src/backend/utils/mb/conversion_procs/ascii_and_mic
cvs server: failed to create lock directory for
Marc, can you set up a cron job to set the permissions automatically?
This seems to happen any time someone adds a new
On Wed, Aug 14, 2002 at 12:11:10AM -0400, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] 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
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
Sorry Bruce, this was included as a part of the patch of the below
subject:
Re: [PATCHES] Dump serials as serial -- not a sequence
Patch may be smart enough to say 'already applied'.
On Wed, 2002-08-14 at 01:29, Bruce Momjian wrote:
Your patch has been added to the PostgreSQL unapplied
I'm going to vote for either @ or %.
On Wed, 2002-08-14 at 00:11, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] 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
Hannu Krosing wrote:
I guess what he meant was that you were arguing for arguments sake (mine
is better than yours! Yes it is! Yes it is! ...)
That's the dictionary definition of the phrase.
and not to get to some
solution,
and that's the source of the frustration. I only re-subscribed
Bruce Momjian wrote:
Christopher Kings-Lynne wrote:
1. The current implementation is broken.
2. We have no proper description of how a fixed implementation
should work.
Surely 99% of the implementation problems could be solved with an index type
that can span tables?
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Is it theoretically possible to add support to btree for storing table along
with the indexed value?
That's what we need, all right.
This would obviously add overhead, so it would only
be done for spanning indexes. The index would also take
On Tue, 2002-08-13 at 23:42, Bruce Momjian wrote:
Curt Sampson wrote:
On Tue, 13 Aug 2002, Bruce Momjian wrote:
Yea, you have to question what value the discussion has, really. We
have users of inheritance that like it. If we can get a TODO item out
of the disucssion, great, but
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
On Wed, 14 Aug 2002, Tom Lane wrote:
Gavin Sherry [EMAIL PROTECTED] writes:
... do we want to modify every 7.2 error message?
Nyet ... but I don't think tacking an offset onto the end of
parse error at or near foo messages is likely to cause the
sort of generalized havoc you suggest ...
On Wed, 2002-08-14 at 08:59, Tom Lane wrote:
There are a veritable ton of other issues to be resolved --- like how do
we (efficiently) find all the indexes relevant to a given child table
--- but the physical storage doesn't seem too complicated.
Tom, seems we have yet another false start.
On Tue, 2002-08-13 at 23:43, Curt Sampson wrote:
Just my opinion of course, but I think it would be best to have a
detailed description of how everything in inheritance is supposed to
work, write a set of tests from that, and then fix the implementation to
conform to the tests.
And I think
Gavin Sherry [EMAIL PROTECTED] writes:
On Wed, 14 Aug 2002, Bruce Momjian wrote:
I think this belongs on gborg. Would you create a project there?
A number of people at OSCON did consider this to be a nice contrib
feature. Out of curiousity, what makes it more suitable for gborg?
I think
Hannu Krosing [EMAIL PROTECTED] writes:
Agreed. Most of this would be easy to implement for curent
implementation (but perhaps no more efficient than when done by manually
added rules/triggers) if constraints could contain subqueries.
I don't understand what a constraint containing a subquery
On Wed, Aug 14, 2002 at 09:39:06AM -0500, Greg Copeland wrote:
On Tue, 2002-08-13 at 23:43, Curt Sampson wrote:
Just my opinion of course, but I think it would be best to have a
detailed description of how everything in inheritance is supposed to
work, write a set of tests from that, and
Ross J. Reedstrom wrote:
Actually, I think you'll find that once a PostgreSQL DBA gets to
the point of designing a sufficently complex schema that inheritance
might be useful, they quickly bump up against the lack of index and
constraint spanning (most notably, referential integrity), and
Do any of the encodings with encoding max length 1 have a constant
character size (e.g. unicode?). If so, how hard would it be to add
another member to pg_wchar_tbl, say:
bool mblen_is_const; /* all chars = max bytes this charset */
Then those character sets code gain back much of the
On Wed, 2002-08-14 at 10:17, Ross J. Reedstrom wrote:
On Wed, Aug 14, 2002 at 09:39:06AM -0500, Greg Copeland wrote:
I completely agree. This is why I want/wanted to pursue the theory and
existing implementations angle.
In theory, it sounds like a good idea. In practice ... ;-)
LOL.
[EMAIL PROTECTED] 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
On Tuesday 13 August 2002 08:07 pm, Curt Sampson wrote:
On Tue, 13 Aug 2002, Lamar Owen wrote:
Curt, I think his reply stems from his frustration of chosen content in
many emails that originate from you. We all pretty well understand
postgres has a broken feature. We all understand
Greg Copeland [EMAIL PROTECTED] writes:
On Tue, 2002-08-13 at 23:43, Curt Sampson wrote:
And I think a detailed description comes most easily when you have
a logical model to work from.
I completely agree. This is why I want/wanted to pursue the theory and
existing implementations angle.
On Tuesday 13 August 2002 03:52 pm, Peter Eisentraut wrote:
Tatsuo Ishii writes:
The $libdir variable is defined at the compile time and it points to
$prefix/lib. Apparently it points to different place while doing
regression tests. One idea is replacing $lindir with the absolute path
to
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
I know this is a off topic. I found this in my mailbox not long ago.
I'm sharing because I thought it might be of some interest. While it's
obviously a PR move by IBM, it certainly was nice to have something of
scale like SF to tout in Postgres' favor as a success story.
Here's a snippet from
On Wed, 2002-08-14 at 11:17, Ross J. Reedstrom wrote:
On Wed, Aug 14, 2002 at 09:39:06AM -0500, Greg Copeland wrote:
On Tue, 2002-08-13 at 23:43, Curt Sampson wrote:
Just my opinion of course, but I think it would be best to have a
detailed description of how everything in inheritance is
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
While the REFERENCES privilege controls who can create foreign keys
referring to one's tables, it seems you can evade it by using CREATE
CONSTRAINT TRIGGER directly.
This is the slave portion of a FK constraint I got from pg_dump:
CREATE CONSTRAINT TRIGGER $1
AFTER INSERT OR UPDATE ON slave
On Wed, 14 Aug 2002, Tom Lane wrote:
Lamar Owen [EMAIL PROTECTED] 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
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
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
I needed to move a PostgreSQL database to another product but I noticed
that the pg_dump output contains a few artifacts that make the output
nonportable. Most of these should be relatively easy to fix. Here's my
list:
* Boolean values should be dumped as true and false (rather than 't' and
On Wed, 2002-08-14 at 12:47, Marc G. Fournier wrote:
On Wed, 14 Aug 2002, Bruce Momjian wrote:
Marc G. Fournier wrote:
They are moving pgaccess more into the admin role, and pgmonitor fit in
with that.
Personally, I kinda like to be able to run admin modularized ... they
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
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
On Wed, 14 Aug 2002, Tom Lane wrote:
Gavin Sherry [EMAIL PROTECTED] writes:
On Wed, 14 Aug 2002, Bruce Momjian wrote:
I think this belongs on gborg. Would you create a project there?
A number of people at OSCON did consider this to be a nice contrib
feature. Out of curiousity, what
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
Peter Eisentraut [EMAIL PROTECTED] writes:
While the REFERENCES privilege controls who can create foreign keys
referring to one's tables, it seems you can evade it by using CREATE
CONSTRAINT TRIGGER directly.
Good point.
It seems we need to check the privilege on the table mentioned in the
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
Thanks. I will keep it in the queue for CVS commit message sake.
---
Rod Taylor wrote:
Sorry Bruce, this was included as a part of the patch of the below
subject:
Re: [PATCHES] Dump serials as serial -- not a
Lamar Owen [EMAIL PROTECTED] 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
interesting.
From: Peter Eisentraut [EMAIL PROTECTED]
To: Bruce Momjian [EMAIL PROTECTED]
CC: Tom Lane [EMAIL PROTECTED],Gavin Sherry [EMAIL PROTECTED],
[EMAIL PROTECTED],[EMAIL PROTECTED]
Subject: Re: [HACKERS] journaling in contrib ...
Date: Thu, 15 Aug 2002 00:01:41 +0200 (CEST)
Sounds good to me. TODO updated:
o Cluster all tables at once using pg_index.indisclustered set
during previous CLUSTER
---
Zeugswetter Andreas SB SD wrote:
Added to TODO:
o Cluster all
Peter Eisentraut [EMAIL PROTECTED] writes:
I needed to move a PostgreSQL database to another product but I noticed
that the pg_dump output contains a few artifacts that make the output
nonportable. Most of these should be relatively easy to fix.
Most of these look like they would break a lot
Bruce Momjian [EMAIL PROTECTED] 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
Tom Lane wrote:
I'd suggest dropping the talk slides (and you might as well flatten the
thing into one directory). Perhaps instead the README could include a
pointer to where to find the talk slides on-line. That'd bring it down
to half a dozen K which is a more appropriate size for a
Do any of the encodings with encoding max length 1 have a constant
character size (e.g. unicode?). If so, how hard would it be to add
another member to pg_wchar_tbl, say:
bool mblen_is_const; /* all chars = max bytes this charset */
Then those character sets code gain back much of
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
Marc G. Fournier wrote:
Anything in contrib that can be built seperately from the server code,
that just requires libpq and headers, should be pulled and distributed as
seperate modules, which has the added benefit that, if listed on GBorg,
search engines will pick up the modules ...
And
[EMAIL PROTECTED] (Bruce Momjian) wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] 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
Peter Eisentraut wrote:
I needed to move a PostgreSQL database to another product but I noticed
^^
Surely this is a misprint. ;-)
that the pg_dump output contains a few artifacts that make the output
nonportable. Most of these
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] 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
Bruce Momjian [EMAIL PROTECTED] 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
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] 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
On Wed, 2002-08-14 at 14:34, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] 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
I have been getting this for at least two days:
[matthew@zeut src]$ cvs -v
Concurrent Versions System (CVS) 1.11.2 (client/server)
[matthew@zeut src]$ cvs -z3 -d
:pserver:[EMAIL PROTECTED]:/projects/cvsroot co -P pgsql
[...]
cvs server: Updating
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
On Wed, 14 Aug 2002, Bruce Momjian wrote:
Marc G. Fournier wrote:
Anything in contrib that can be built seperately from the server code,
that just requires libpq and headers, should be pulled and distributed as
seperate modules, which has the added benefit that, if listed on GBorg,
Marc G. Fournier wrote:
On Wed, 14 Aug 2002, Bruce Momjian wrote:
Marc G. Fournier wrote:
Anything in contrib that can be built seperately from the server code,
that just requires libpq and headers, should be pulled and distributed as
seperate modules, which has the added benefit
Anyone mind if we bump the DTD version to Docbook 4.2?
This consists on all users who wish to build docs on installing the 4.2
DTD set, and updating some depreciated tags within the sgml files.
comment - remark
docinfo - appendixinfo, chapterinfo, bookinfo, etc.
What it buys is a number of
Reading about the pgmonitor thread and mention of gborg made me wonder
about replication and ready ability to uniformly monitor it. Just as
pg_stat* tables exist to allow for statistic gathering and monitoring in
a uniform fashion, it occurred to me that a predefined set of views
and/or tables
Lamar Owen [EMAIL PROTECTED] 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?
Bruce Momjian [EMAIL PROTECTED] 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 ...
On Wed, 14 Aug 2002, Bruce Momjian wrote:
Marc G. Fournier wrote:
On Wed, 14 Aug 2002, Bruce Momjian wrote:
Marc G. Fournier wrote:
Anything in contrib that can be built seperately from the server code,
that just requires libpq and headers, should be pulled and distributed as
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] 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 ...
Marc G. Fournier wrote:
They are moving pgaccess more into the admin role, and pgmonitor fit in
with that.
Personally, I kinda like to be able to run admin modularized ... they
*should* be looking at stuff like webmin, where you can plug-n-play admin
functions as required, or horde
Greg Copeland [EMAIL PROTECTED] writes:
... it occurred to me that a predefined set of views
and/or tables for all replication implementations may be worthwhile.
Do we understand replication well enough to define such a set of views?
I sure don't ...
regards, tom lane
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.
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
On Wed, 2002-08-14 at 16:32, Neil Conway wrote:
A couple questions regarding encrypted passwords:
(1) There was talk of changing the default value of the
'password_encryption' GUC variable for 7.3; AFAIK, this hasn't
happened yet. Should this be done?
Since ODBC is capable of using
Bruce Momjian writes:
OK, we got _that_ answer. Looks like gborg. Marc really wants to pump
that up.
I think if gborg had a different name and looked more like the main site,
more people would consider using it without feeling kicked out.
--
Peter Eisentraut [EMAIL PROTECTED]
Christopher Kings-Lynne writes:
How can I modify it to build two different C files into two different .so's?
That is next to impossible in the current setup.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 1: subscribe
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
Tom Lane writes:
Most of these look like they would break a lot of people --- for
example, we can't just arbitrarily change the results of bool_out.
That wouldn't help anyway. I meant to add code in pg_dump (and possibly
the rule recompiler). That doesn't break anything.
You mean you'd
Neil Conway wrote:
A couple questions regarding encrypted passwords:
(1) There was talk of changing the default value of the
'password_encryption' GUC variable for 7.3; AFAIK, this hasn't
happened yet. Should this be done?
Strange. I had updated the docs and postgresql.conf, but
Rod Taylor wrote:
On Wed, 2002-08-14 at 16:32, Neil Conway wrote:
A couple questions regarding encrypted passwords:
(1) There was talk of changing the default value of the
'password_encryption' GUC variable for 7.3; AFAIK, this hasn't
happened yet. Should this be done?
Peter Eisentraut wrote:
I will vote against this as being a major loss of legibility. Perhaps
we could compromise on controlling it by a GUC variable, though.
I was afraid of that, but to pick up the theme of the day, I'm not sure if
I want to overcomplexify things that much. ;-)
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
Neil Conway [EMAIL PROTECTED] writes:
A couple questions regarding encrypted passwords:
(1) There was talk of changing the default value of the
'password_encryption' GUC variable for 7.3; AFAIK, this hasn't
happened yet. Should this be done?
Hmm. I thought it *was* done, but it
Tom Lane wrote:
Hmm. I thought it *was* done, but it looks like Bruce forgot to change
the actual guc.c value? The docs and postgresql.conf.sample claim the
default is true...
2002-06-14 21:29 momjian
* doc/src/sgml/runtime.sgml,
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane writes:
Most of these look like they would break a lot of people --- for
example, we can't just arbitrarily change the results of bool_out.
That wouldn't help anyway. I meant to add code in pg_dump (and possibly
the rule recompiler).
Bruce Momjian [EMAIL PROTECTED] 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
On Thu, 15 Aug 2002, Peter Eisentraut wrote:
Bruce Momjian writes:
OK, we got _that_ answer. Looks like gborg. Marc really wants to pump
that up.
I think if gborg had a different name and looked more like the main site,
more people would consider using it without feeling kicked out.
Bruce Momjian [EMAIL PROTECTED] writes:
It also allowed auto-migration to encrypted passwords from an old dump
file.
Ah, right, that was it: we wanted to be able to have a pg_dumpall script
containing a mix of crypted and noncrypted passwords in CREATE USER
commands be loaded either as-is, or
On 14 Aug 2002, Oliver Elphick wrote:
cvs server: Updating src/backend/utils/mb/conversion_procs/ascii_and_mic
cvs server: failed to create lock directory for
`/projects/cvsroot/pgsql-server/src/backend/utils/mb/conversion_procs/ascii_and_mic'
On Wed, 2002-08-14 at 18:20, Bruce Momjian wrote:
Peter Eisentraut wrote:
I will vote against this as being a major loss of legibility. Perhaps
we could compromise on controlling it by a GUC variable, though.
I was afraid of that, but to pick up the theme of the day, I'm not sure if
On Wed, 14 Aug 2002, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] 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,
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] 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
Bruce Momjian [EMAIL PROTECTED] 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
On Wed, 14 Aug 2002, Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] 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
On Wed, 14 Aug 2002, Tom Lane wrote:
I agree. Table-spanning indexes would be a large, complex,
difficult-to-get-right feature. Before diving into that we should get
some idea of just how we'd actually use them, and whether that's the
only big chunk of work standing between us and a more
Curt Sampson [EMAIL PROTECTED] writes:
That's my biggest fear as well. Here are a couple of possible
assertions we could make about supertables and subtables that have,
I think, some fairly far-reaching implications.
CHECK-style constraints don't seem like a huge issue to me. We already
have
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] 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
1 - 100 of 133 matches
Mail list logo
