I have to say that during beta testing I ALWAYS do an initdb and a reload
just to make sure the pg_dumpall and pg_restore stuff works right. Plus
to make sure problems that might only pop up with a new initdb are found
as well. I probably "burn it to the ground" several times on a single
bet
Can I buy an extra day or two? I'm in DC till Saturday then there's the
trip home. How 'bout a wednesday beta release?
On Thu, 19 Sep 2002, Marc G. Fournier wrote:
> On Wed, 18 Sep 2002, Tom Lane wrote:
>
> > "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > > ... I'm going to do up a beta2
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
> Yeah, we should do something with that. Are people okay with the idea
> of CREATE LANGUAGE, etc, retroactively changing prorettype from OPAQUE
> to the correct thing?
>
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Tom Lane writes:
> >> Yeah, we should do something with that. Are people okay with the idea
> >> of CREATE LANGUAGE, etc, retroactively changing prorettype from OPAQUE
> >> to the correct thing?
>
> > Seems like an appropriate ti
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> Yeah, we should do something with that. Are people okay with the idea
>> of CREATE LANGUAGE, etc, retroactively changing prorettype from OPAQUE
>> to the correct thing?
> Seems like an appropriate time to throw a notice, though.
Tom Lane writes:
> Yeah, we should do something with that. Are people okay with the idea
> of CREATE LANGUAGE, etc, retroactively changing prorettype from OPAQUE
> to the correct thing?
Seems like an appropriate time to throw a notice, though.
--
Peter Eisentraut [EMAIL PROTECTED]
---
Tom Lane wrote:
> AFAICS, getting SIMILAR TO to operate per spec would require adding some
> sort of translation function that converts the spec-style pattern into
> a Posix pattern that our regex match engine would handle. This would at
> least require adding ^ and $ around the pattern, converti
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> Right, so you have two telling you to remove it, one telling you to add
> it, and two that are discussion why/if it *should* be added ... Tom feels
> it should be added, and I'm clarifing the why of it ... don't re-add it
> until we've determined *
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> Who implemented SIMILAR TO in the first place?
Thomas. He put in the syntax, but as it stands it's simply syntactic
sugar for ~ --- that is, our Posix-compatible regex match operator.
Since the spec demands very non-Posix behavior, this is wrong.
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Looking at the open item list, I see:
> fix up function return types on lang/type/trigger creation or
> loosen opaque restrictions
> Seems that should be fixed before beta2 because it does effect people
> loading data.
Yeah, we should
On Thu, 19 Sep 2002, Bruce Momjian wrote:
> Marc G. Fournier wrote:
> > On Thu, 19 Sep 2002, Bruce Momjian wrote:
> >
> > >
> > > It is an open issue. It has to be resolved. When it is, I will remove
> > > it. I added a question mark to it but it needs to be tracked. I keep
> > > having to add
Marc G. Fournier wrote:
> On Thu, 19 Sep 2002, Bruce Momjian wrote:
>
> >
> > It is an open issue. It has to be resolved. When it is, I will remove
> > it. I added a question mark to it but it needs to be tracked. I keep
> > having to add and remove it because I have people telling me what to
On Thu, 19 Sep 2002, Bruce Momjian wrote:
>
> It is an open issue. It has to be resolved. When it is, I will remove
> it. I added a question mark to it but it needs to be tracked. I keep
> having to add and remove it because I have people telling me what to do.
>
> It was Peter who told me to
It is an open issue. It has to be resolved. When it is, I will remove
it. I added a question mark to it but it needs to be tracked. I keep
having to add and remove it because I have people telling me what to do.
It was Peter who told me to add it, and you and Thomas to remove it. It
isn't me
On Wed, 18 Sep 2002, Bruce Momjian wrote:
>
> Re-added to open items:
>
> Fix SIMILAR TO to be ANSI compliant or remove it (Peter, Tom)
Tke that @#$@$@@$@#$ thing out of there until its actually been fully
discussed ... you are starting to remind me of Charlie Brown ... this, I
think, was
On Wed, 18 Sep 2002, Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > I'm in agreement with Thomas here ... unless a problem has been defined a
> > bit more specifically then 'it isn't posix compliant', it shouldn't be
> > considered an open item ... please remove?
>
> A quick
On Wed, 18 Sep 2002, Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > ... I'm going to do up a beta2 on Friday due to the number changes
> > that have been committed over the past 2 weeks ...
>
> I want to review and apply Alvaro's attisinherited fix before we go
> beta2. I t
Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > ... I'm going to do up a beta2 on Friday due to the number changes
> > that have been committed over the past 2 weeks ...
>
> I want to review and apply Alvaro's attisinherited fix before we go
> beta2. I think I can get that d
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> ... I'm going to do up a beta2 on Friday due to the number changes
> that have been committed over the past 2 weeks ...
I want to review and apply Alvaro's attisinherited fix before we go
beta2. I think I can get that done tomorrow. I can't recal
Re-added to open items:
Fix SIMILAR TO to be ANSI compliant or remove it (Peter, Tom)
---
Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > I'm in agreement with Thomas here ... unless a problem
> I completely agree with Bruce here. Requiring an initdb for every beta
> release significantly reduces the number of people who will be willing
> to try it out -- so initdb's between betas are not disasterous, but
> should be avoided if possible.
But it does mean that 7.3 to 7.3 pg_dump gets a
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> On Wed, 18 Sep 2002, Bruce Momjian wrote:
> > We should get _all_ the known initdb-related issues into the code
> > before we go beta2 or beta3 is going to require another initdb.
>
> Right, and? How many times in the past has it been the last bet
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> I'm in agreement with Thomas here ... unless a problem has been defined a
> bit more specifically then 'it isn't posix compliant', it shouldn't be
> considered an open item ... please remove?
A quick review of SQL99 says that their notion of SIMILA
Marc G. Fournier wrote:
> On Wed, 18 Sep 2002, Bruce Momjian wrote:
>
> > I think you are confusing the open items list with the TODO list. TODO
> > usually has some basis, while open items is just that, things we need to
> > decide on. Peter brought it up and wanted it on the list so I put it
Marc G. Fournier wrote:
> On Wed, 18 Sep 2002, Bruce Momjian wrote:
>
> > Marc G. Fournier wrote:
> > > On Wed, 18 Sep 2002, Bruce Momjian wrote:
> > >
> > > > We are going to require an initdb for beta2 and I think we need to get
> > > > _everything_ required in there before going to beta2. See
On Wed, 18 Sep 2002, Bruce Momjian wrote:
> I think you are confusing the open items list with the TODO list. TODO
> usually has some basis, while open items is just that, things we need to
> decide on. Peter brought it up and wanted it on the list so I put it
> on. I can be taken off just as
On Wed, 18 Sep 2002, Bruce Momjian wrote:
> Marc G. Fournier wrote:
> > On Wed, 18 Sep 2002, Bruce Momjian wrote:
> >
> > > We are going to require an initdb for beta2 and I think we need to get
> > > _everything_ required in there before going to beta2. See the open
> > > items list. I think w
Marc G. Fournier wrote:
> On Wed, 18 Sep 2002, Bruce Momjian wrote:
>
> > We are going to require an initdb for beta2 and I think we need to get
> > _everything_ required in there before going to beta2. See the open
> > items list. I think we will need until the middle of next week for
> > beta
Marc G. Fournier wrote:
> Well, if nobody can identify what exactly the problem is, it should
> definitely be removed from the Open Items list ... maybe we need to lay
> down some 'rules' for the TODO list? Some sort of criteria other hten
> "someone suggested it" to work with? For instance, cha
On Wed, 18 Sep 2002, Bruce Momjian wrote:
> We are going to require an initdb for beta2 and I think we need to get
> _everything_ required in there before going to beta2. See the open
> items list. I think we will need until the middle of next week for
> beta2. In fact, I have the inheritance
On Wed, 18 Sep 2002, Bruce Momjian wrote:
> Thomas Lockhart wrote:
> > ...
> > > Fix SIMILAR TO to be Posix compiant or remove it
> >
> > Sorry, was there a decision here?
> >
> > No one has described the problem, just declared that there is one and
> > declared that the feature should be removed
Marc G. Fournier wrote:
> On Wed, 18 Sep 2002, Sean Chittenden wrote:
>
> > > There has been a lot of activity on open items in the past week. Here
> > > is the updated list.
> > >
> > > Basically, upgrading and casting have blown up into a variety of items.
> >
> > What's the timeframe for beta
On Wed, 18 Sep 2002, Sean Chittenden wrote:
> > There has been a lot of activity on open items in the past week. Here
> > is the updated list.
> >
> > Basically, upgrading and casting have blown up into a variety of items.
>
> What's the timeframe for beta2? FreeBSD's going into a ports freeze
Marc G. Fournier wrote:
> On Wed, 18 Sep 2002, Bruce Momjian wrote:
>
> > On Going
> >
> > Point-in-time recovery
> > Win32 port
>
> these have nothing to do with v7.3, so shouldn't even be listed here ...
OK, removed.
--
Bruce Momjian| http://candle.pha.pa
On Wed, 18 Sep 2002, Bruce Momjian wrote:
> On Going
>
> Point-in-time recovery
> Win32 port
these have nothing to do with v7.3, so shouldn't even be listed here ...
---(end of broadcast)---
TIP 6: Have you searched our list archives?
Thomas Lockhart wrote:
> ...
> > Fix SIMILAR TO to be Posix compiant or remove it
>
> Sorry, was there a decision here?
>
> No one has described the problem, just declared that there is one and
> declared that the feature should be removed.
>
> In the old days, one might have expected to approa
Sean Chittenden wrote:
> > There has been a lot of activity on open items in the past week. Here
> > is the updated list.
> >
> > Basically, upgrading and casting have blown up into a variety of items.
>
> What's the timeframe for beta2? FreeBSD's going into a ports freeze
> on Friday and I'd
Gavin Sherry wrote:
> > Change log_min_error_statement to be off by default (Gavin)
>
> I will be happy to provide this simple fix once I can get some indication
> of the preferred implication. The discussion left off with Bruce prefering
> that the GUC code for the *_min_* variables be variable
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > There has been a lot of activity on open items in the past week. Here
> > is the updated list.
>
> SIMILAR TO and the associated SUBSTRING functionality need to be fixed.
>
Added to open items:
Fix SIMILAR TO to be Posix compiant
Bruce Momjian writes:
> There has been a lot of activity on open items in the past week. Here
> is the updated list.
SIMILAR TO and the associated SUBSTRING functionality need to be fixed.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)-
> There has been a lot of activity on open items in the past week. Here
> is the updated list.
>
> Basically, upgrading and casting have blown up into a variety of items.
What's the timeframe for beta2? FreeBSD's going into a ports freeze
on Friday and I'd be slick to see it ship with 7.3beta2
> Change log_min_error_statement to be off by default (Gavin)
I will be happy to provide this simple fix once I can get some indication
of the preferred implication. The discussion left off with Bruce prefering
that the GUC code for the *_min_* variables be variable specific where as
Tom saw no n
Tom Lane: "And with the availability of schemas in 7.3, I think that
multiple databases per installation is going to become less common to
begin with --- people will more often use multiple schemas in one big
database if they want the option of data sharing, or completely
separate installations if
Oliver Elphick <[EMAIL PROTECTED]> 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 coul
On Tue, 2002-08-27 at 23:10, Tom Lane wrote:
> Oliver Elphick <[EMAIL PROTECTED]> 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 n
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 @dbnam
Tom Lane wrote:
> Oliver Elphick <[EMAIL PROTECTED]> 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
Oliver Elphick <[EMAIL PROTECTED]> 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
;-)
r
Oliver Elphick <[EMAIL PROTECTED]> 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 c
On Tue, 2002-08-27 at 22:44, Tom Lane wrote:
> Oliver Elphick <[EMAIL PROTECTED]> 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,
Peter Eisentraut <[EMAIL PROTECTED]> 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 user
Oliver Elphick <[EMAIL PROTECTED]> 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-fi
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
> >
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 princ
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 d
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
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
> usernam
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 '@
Yes, this is the counter case, where the '@' disappears; so it appears
magically for local users, and disappears for global users.
---
Robert Treat wrote:
> Is the converse to this:
>
> $ psql -U postgres@ test
>
> Welco
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
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 per
Bruce Momjian <[EMAIL PROTECTED]> 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
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 us
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
I think we need to resolve this discussion from a week ago. The current
code is this:
global usernames are stored just like before, e.g. postgres
local users are stored as user@dbname
when connecting, global users add '@' to their names
when connecting, local use
On Sat, Aug 17, 2002 at 11:08:45PM -0400, Bruce Momjian wrote:
>
> integrate or move to gborg libpqxx, Pg:DBD
It's no longer my CVS home tree... Is there something I can/should
do for this?
Jeroen
---(end of broadcast)---
TIP 1: subscribe and
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 n
[EMAIL PROTECTED] (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.
> It might be worth recalling the
Peter Eisentraut <[EMAIL PROTECTED]> 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
Tom Lane writes:
> Peter Eisentraut <[EMAIL PROTECTED]> 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.
On Sat, 17 Aug 2002, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> 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
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 user
Peter Eisentraut <[EMAIL PROTECTED]> 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 cou
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
OK, applied, with that change.
---
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > OK, here is the patch with the suggested changes. I am sending the
> > patch to hackers because there has been so much inte
Bruce Momjian <[EMAIL PROTECTED]> 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->us
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> 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
Bruce Momjian <[EMAIL PROTECTED]> 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 c
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@' an
Sample run:
$ psql -U postgres test
psql: FATAL: user "postgres@test" does not exist
$ psql -U postgres@ test
Welcome to psql 7.3devel, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for h
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 elimi
[EMAIL PROTECTED] wrote:
> [EMAIL PROTECTED] (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 th
[EMAIL PROTECTED] (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_STUPI
On Fri, 16 Aug 2002 12:25:37 -0400 (EDT), Bruce Momjian
<[EMAIL PROTECTED]> wrote:
>Manfred Koizar wrote:
>> This is the main point of disagreement: Tom Lane wants lighter
>> macros, I want heavier macros. Which direction shall we go?
>
>Could you or Tom explain that in a way that others could u
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 a
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. The
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:
Vince Vielhaber <[EMAIL PROTECTED]> 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
woul
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
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
> n
On Fri, 16 Aug 2002, Tom Lane wrote:
> Lee Kindness <[EMAIL PROTECTED]> 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 o
Bruce Momjian <[EMAIL PROTECTED]> 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
nam
Manfred Koizar wrote:
> On Fri, 16 Aug 2002 01:05:07 -0400 (EDT), Bruce Momjian
> <[EMAIL PROTECTED]> wrote:
> >
> > P O S T G R E S Q L
> >
> > 7 . 3 O P E NI T E M S
> >
> >improve macros in new tuple header code (Manfred)
>
> ISTM ther
On Fri, 16 Aug 2002 01:05:07 -0400 (EDT), Bruce Momjian
<[EMAIL PROTECTED]> wrote:
>
> P O S T G R E S Q L
>
> 7 . 3 O P E NI T E M S
>
>improve macros in new tuple header code (Manfred)
ISTM there's no consensus about what "improve" mean
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 wil
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Reindex/btree shrinkage - does reindex need work, can btree be shrunk?
>
> I think there is zero probability that anything will be finished on this
> in the next two weeks, considering that (a) no one is working on it,
> and (b) it's
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
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
Lee Kindness <[EMAIL PROTECTED]> 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.
>
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 t
1 - 100 of 301 matches
Mail list logo
