On Tuesday 21 June 2005 10:04, Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > You know, since we don't maintain static connections (http is our friend)
> > connecting to template1 really isn't a problem for phppgadmin users. At
> > least I can't remember anyone ever having complain
Tom Lane wrote:
Robert Treat <[EMAIL PROTECTED]> writes:
You know, since we don't maintain static connections (http is our friend)
connecting to template1 really isn't a problem for phppgadmin users. At
least I can't remember anyone ever having complained about it.
Sure you have:
Robert Treat <[EMAIL PROTECTED]> writes:
> You know, since we don't maintain static connections (http is our friend)
> connecting to template1 really isn't a problem for phppgadmin users. At
> least I can't remember anyone ever having complained about it.
Sure you have: people have complained a
"Dave Page" writes:
>> Another point is that Dave added code to pg_dumpall to not dump the
>> postgres database.
> My reading of that code was that I merely stopped it dumping the CREATE
> DATABASE statement (and the ACL) for the database, /not/ the actual
> contents - in the same way as is done
gander; pgsql-hackers@postgresql.org
> > Subject: Re: [HACKERS] [PATCHES] default database creation with initdb
> >
> > > Yes - that's intentional so that pgAdmin/phpPgAdmin et al. can
> > > reasonably expect it to be there.
> >
> > Problem is, how the
Tom Lane wrote:
One thing that neither Dave nor I wanted to touch is pg_autovacuum.
If that gets integrated into the backend by feature freeze then the
question is moot, but if it doesn't then we'll have to decide whether
autovac should preferentially connect to template1 or postgres. Neither
c
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: 21 June 2005 05:13
> To: Dave Page
> Cc: Andrew Dunstan; Andreas Pflug; Robert Treat; Magnus
> Hagander; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] [PATCHES] default database cr
> -Original Message-
> From: Christopher Kings-Lynne [mailto:[EMAIL PROTECTED]
> Sent: 21 June 2005 08:57
> To: Dave Page
> Cc: Robert Treat; Tom Lane; Andrew Dunstan; Andreas Pflug;
> Magnus Hagander; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] [PATC
Yes - that's intentional so that pgAdmin/phpPgAdmin et al. can
reasonably expect it to be there.
Problem is, how the hell do I know it's there before I connect?
Chris
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send
> -Original Message-
> From: Robert Treat [mailto:[EMAIL PROTECTED]
> Sent: 21 June 2005 08:10
> To: Tom Lane
> Cc: Dave Page; Andrew Dunstan; Andreas Pflug; Magnus
> Hagander; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] [PATCHES] default database
On Tuesday 21 June 2005 00:12, Tom Lane wrote:
> "Dave Page" writes:
> > OK, new patch posted to -patches that updates all the utilities as well.
>
If I read the code correctly, the database name will be hardwired to
"postgres" regardless of the default super user name correct?
--
Robert Trea
Tom Lane wrote:
Another point is that Dave added code to pg_dumpall to not dump the
postgres database. This seems mistaken to me, so I did not include it
in the applied patch: if someone is doing real work in postgres then
they'll be pretty annoyed if it's not backed up. But perhaps the
questio
"Dave Page" writes:
> OK, new patch posted to -patches that updates all the utilities as well.
Applied.
One thing that neither Dave nor I wanted to touch is pg_autovacuum.
If that gets integrated into the backend by feature freeze then the
question is moot, but if it doesn't then we'll have to d
"Dave Page" writes:
>> I don't see that much of a problem with having createdb etc. hardwire
>> postgres instead of template1 as the db-to-connect-to.
> OK, new patch posted to -patches that updates all the utilities as well.
I'm going to apply this this evening (ie, before any of the code drif
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
If it's a server-side failure it should have a SQLSTATE code.
Specifically, I'm talking about
"no pg_hba.conf entry for ",
ERRCODE_INVALID_AUTHORIZATION_SPECIFICATION
"Ident authentication failed.." (b
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: 20 June 2005 14:19
> To: Andrew Dunstan
> Cc: Dave Page; Andreas Pflug; Robert Treat; Magnus Hagander;
> pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] [PATCHES] default database cr
Andreas Pflug <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> If it's a server-side failure it should have a SQLSTATE code.
> Specifically, I'm talking about
> "no pg_hba.conf entry for ",
ERRCODE_INVALID_AUTHORIZATION_SPECIFICATION
> "Ident authentication failed.." (both server sice)
Dit
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
Fallback is a fine idea, but this brings up another problem I'm
currently facing: how to identify the problem the connection has from
libpq? If the problem is a wrong password, we certainly don't want to
try again. I browsed the source
Andreas Pflug <[EMAIL PROTECTED]> writes:
> Fallback is a fine idea, but this brings up another problem I'm
> currently facing: how to identify the problem the connection has from
> libpq? If the problem is a wrong password, we certainly don't want to
> try again. I browsed the sources over and
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Dave Page wrote:
>> That's what I'm working on atm, and given Tom's previous comment about
>> small-footprint users not wanting an extra 5/6MB on the size of a new
>> cluster, I'm leaving most things using template1 and mainly just
>> updating docs and e
> -Original Message-
> From: Andrew Dunstan [mailto:[EMAIL PROTECTED]
> Sent: 20 June 2005 10:41
> To: Dave Page
> Cc: Andreas Pflug; Tom Lane; Robert Treat; Magnus Hagander;
> pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] [PATCHES] default database
Dave Page wrote:
That's what I'm working on atm, and given Tom's previous comment about
small-footprint users not wanting an extra 5/6MB on the size of a new
cluster, I'm leaving most things using template1 and mainly just
updating docs and examples. 'postgres' can then be dropped with no ill
e
Andrew Dunstan wrote:
The decision which files should be changed must be taken. e.g.
createdb, dropdb will use template1 hardcoded. Is it acceptable that
those tools fail if the "postgres" database isn't present any more?
How about template1 as a fallback?
Fallback is a fine idea,
Andreas Pflug wrote:
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
Can't tell whether I could find time for reviewing the docs the next
days (more interesting for feature freeze is having fixed the
implementation anyway).
Of the sixty-odd files that mention template1 in cu
> -Original Message-
> From: Andreas Pflug [mailto:[EMAIL PROTECTED]
> Sent: 20 June 2005 10:14
> To: Tom Lane
> Cc: Dave Page; Robert Treat; Magnus Hagander;
> pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] [PATCHES] default database creation with initd
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
Can't tell whether I could find time for reviewing the docs the next
days (more interesting for feature freeze is having fixed the
implementation anyway).
Of the sixty-odd files that mention template1 in current CVS, only about
half
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: 20 June 2005 03:46
> To: Andreas Pflug
> Cc: Dave Page; Robert Treat; Magnus Hagander;
> pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] [PATCHES] default database creation
> with in
Andreas Pflug <[EMAIL PROTECTED]> writes:
> Can't tell whether I could find time for reviewing the docs the next
> days (more interesting for feature freeze is having fixed the
> implementation anyway).
Of the sixty-odd files that mention template1 in current CVS, only about
half are documentati
Josh Berkus writes:
>> What about just calling the new database postgres by default?
> Hey, works for me. A great idea really.
Yeah, that seems like a pretty good compromise to me too. I was
thinking last night that we'd end up with documentation statements
like "you connect to the default da
Dave Page wrote:
Whether or not users should write to the default db is another issue
altogether, and one that I'd rather not see causing this idea to be
rejected or get delayed past freeze.
+1
If 'default' is writeable, then
so what if users use it? It won't stop pgAdmin from working,
-Original Message-
From: [EMAIL PROTECTED] on behalf of Andreas Pflug
Sent: Sun 6/19/2005 12:23 AM
To: Tom Lane
Cc: Robert Treat; Magnus Hagander; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] [PATCHES] default database creation with initdb
> This contradicts my intention
Thomas,
> What about just calling the new database postgres by default?
Hey, works for me. A great idea really.
H except ... on BSD platforms, due to history with Ports, the
superuser is "pgsql". Fortunately, the BSDs only account for a small
minority of new users, so we could jus
What about just calling the new database postgres by default?
For true newbies, the first thing that happens if you try just
running psql with no arguments is that you discover there's no
database named postgres. For most first-time users, I suspect the
postgres user is the super-user and t
Tom Lane wrote:
[ redirected back to hackers, since it seems this is far from a finished
discussion ]
Robert Treat <[EMAIL PROTECTED]> writes:
What is the purpose of this database? A generalized, shared resource for tool
makers and add-on packages to store information in PostgreSQL, or a wor
Am Samstag, den 18.06.2005, 10:12 -0400 schrieb Tom Lane:
> [ redirected back to hackers, since it seems this is far from a finished
> discussion ]
>
...
> pg_addons or pg_tools or something like that seems like a fine name *for
> the purpose of a tools-only database* ... but that is only one of
[ redirected back to hackers, since it seems this is far from a finished
discussion ]
Robert Treat <[EMAIL PROTECTED]> writes:
> What is the purpose of this database? A generalized, shared resource for tool
> makers and add-on packages to store information in PostgreSQL, or a working
> database
36 matches
Mail list logo
