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
beta
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 and remove it
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 do
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.
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 *if* it
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, converting
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]
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 on Friday
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.
Of
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 time to throw a
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?
Seems
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.
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
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
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 be slick
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 approach this
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?
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.us
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
on
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 beta2? FreeBSD's
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.
In the
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
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, change
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
beta2. In
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 we will need
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
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 the open
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
on.
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 SIMILAR TO
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 beta in
the
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
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 has
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 recall any
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 done
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 think I can
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
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
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 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 do.
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.
---
P O S T G R E S Q L
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
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
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
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
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
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
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
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
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
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
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.
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-file
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
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, we are
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
;-)
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
I say
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
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
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
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
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 could
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
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
just
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. AFAICS 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
[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.
snip
It might be worth recalling the
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@'
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
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 before,
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-user,
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 interest
As you can see, the open items list is greatly shrunk. We have two
weeks to go and most of these seems do-able, except for point-in-time
recovery, which may not make it. I haven't heard anything recently on
it.
Would someone put together a porting document for schema changes and
drop column
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
Vince Vielhaber [EMAIL PROTECTED] 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
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 not a small task. Push it
On Fri, 16 Aug 2002, Tom Lane wrote:
Vince Vielhaber [EMAIL PROTECTED] 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
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
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.
Having read
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
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
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 not a
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
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 means. I
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 there's no consensus
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
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 of programs and
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
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
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
would
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:
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
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
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
[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
[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 the feature,
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
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
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,
Mike Mascari [EMAIL PROTECTED] 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
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
1 - 100 of 282 matches
Mail list logo
