"Dave Page" writes:
> Keeping people out of template1 is my major concern, however it seemed like
> a good way to kill 2 birds with one stone and solve both problems at once.
FWIW here's a "me too" on keeping people out of template1 by default. I've
more than once accidentally created objects i
On Fri, 17 Jun 2005, Andrew Dunstan wrote:
Thus, "sys_shared", "def_share", "user_commons" are all sorts of names
that suggest that this is some sort of default/shared area.
I like the first. The second and third seem less obvious to me.
'default_shared' should definitely get the point across,
Magnus Hagander wrote:
I was gradually drifting toward this idea. Do we really need
the blessing of the postgresql core to make this happen? ISTM
we don't.
I think not, but I would perhaps make things easier ;-)
But what if we all just agreed that we would use a common
database called "
> I was gradually drifting toward this idea. Do we really need
> the blessing of the postgresql core to make this happen? ISTM
> we don't.
I think not, but I would perhaps make things easier ;-)
> But what if we all just agreed that we would use a common
> database called "pg_addons", and t
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Sat 6/18/2005 6:36 AM
To: Dave Page
Cc: Andreas Pflug; Christopher Kings-Lynne; Magnus Hagander; Josh Berkus;
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Utility database (Was: RE: Autovacuum in the backend
On Saturday 18 June 2005 01:36, Tom Lane wrote:
> "Dave Page" writes:
> > Personally I prefer the first or last, as default implies to me that
> > it's a kindof general use database - which, as Tom points out it could
> > be, however I think it's better to encourage users to only use it as
> > dir
"Dave Page" writes:
> I like the first. The second and third seem less obvious to me.
> 'default_shared' should definitely get the point across, though it's a
> little long.
I think "shared" would give the wrong impression to many people ---
nowadays the connotation of that is something that you
"Dave Page" writes:
> Personally I prefer the first or last, as default implies to me that
> it's a kindof general use database - which, as Tom points out it could
> be, however I think it's better to encourage users to only use it as
> directed by tool providers, and not for general purpose.
If
Andrew Dunstan wrote:
It strikes me that these names just might have some significance to
developers but will have none at all for users. I don't heve a better
alternative ... maybe because the purpose has been expressed somewhat
fuzzily.
I'd define the purpose like this:
- being a db
Dave Page wrote:
Thus, "sys_shared", "def_share", "user_commons" are all sorts of names
that suggest that this is some sort of default/shared area.
I like the first. The second and third seem less obvious to me.
'default_shared' should definitely get the point across, though it's a
litt
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Christopher Browne
> Sent: 17 June 2005 19:59
> To: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Utility database
>
> Thus, "sys_shared", "d
> -Original Message-
> From: Andreas Pflug [mailto:[EMAIL PROTECTED]
> Sent: 17 June 2005 18:45
> To: Tom Lane
> Cc: Christopher Kings-Lynne; Magnus Hagander; Dave Page; Josh
> Berkus; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Utility database (Was:
In the last exciting episode, dpage@vale-housing.co.uk ("Dave Page") wrote:
>> But then dbas will block off access to that db, or drop it and
>> we're back to square one...
>
> That's their choice though, and it would then be up to them to
> provide an alternative for their users (there's nothing t
Martha Stewart called it a Good Thing when [EMAIL PROTECTED] (Andreas Pflug)
wrote:
> Magnus Hagander wrote:
>>> I dislike the name pg_system because it implies that that DB is
>>> somehow special from the point of view of the system ... which is
>>> exactly what it would *not* be.
>> That I can c
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: 17 June 2005 15:09
> To: Christopher Kings-Lynne
> Cc: Andreas Pflug; Magnus Hagander; Dave Page; Josh Berkus;
> pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Utility database (Was:
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
I particularly dislike the name "default" for that database, because
we'd have to expect users to place their user data there regularly (as
in the public schema), which is just what should *not* happen.
Why not?
Any tools using this
Andreas Pflug <[EMAIL PROTECTED]> writes:
> I particularly dislike the name "default" for that database, because
> we'd have to expect users to place their user data there regularly (as
> in the public schema), which is just what should *not* happen.
Why not?
Any tools using this database for t
Tom Lane wrote:
One argument against this is that it'd mean another copy of the system
catalogs in a standard installation. That's been running three to five
megabytes over the last few releases. Disk space is pretty cheap these
days, but we do get occasional complaints from people who wish th
Magnus Hagander wrote:
I dislike the name pg_system because it implies that that DB
is somehow special from the point of view of the system ...
which is exactly what it would *not* be.
That I can certainly agree with.
I suggested the name to indicate that it's a db used by system tools
> > It wouldn't just be "default to connect to", it would also be
> > "location for tools to store cluster-wide information". Which makes
> > pg_system a slightly more reasonable name in that context, but i
> > certainly have no problem with "default" as a name.
>
> Well, where a tool chooses t
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> It wouldn't just be "default to connect to", it would also be "location
> for tools to store cluster-wide information". Which makes pg_system a
> slightly more reasonable name in that context, but i certainly have no
> problem with "default" as a name
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> So may I propose to have a pg_system database created by initdb, as a
>> copy from template1 in 8.1?
Seems like a bizarre choice of name. Why not "default"?
> But then dbas will block off access to that db, or drop it and we're
> back to s
> > But then dbas will block off access to that db, or drop it
> and we're
> > back to square one...
>
> Don't see why they would. Let's review what we have here:
>
> Database Function(s)
>
> template0 guaranteed-virgin template for CREATE DATABASE
>
> template1
Christopher Kings-Lynne wrote:
Probably, though the create db issue is a good reason not to use
template1.
Create db issue?
CREATE TABLE (implicitely using TEMPLATE template1) often fails because
template1 has connections exceeding the current one.
So may I propose to have a pg_system d
-Original Message-
From: Christopher Kings-Lynne [mailto:[EMAIL PROTECTED]
Sent: Fri 6/17/2005 11:00 AM
To: Andreas Pflug
Cc: Magnus Hagander; Dave Page; Josh Berkus; pgsql-hackers@postgresql.org; Tom
Lane
Subject: Re: [HACKERS] Utility database (Was: RE: Autovacuum in the backend
-Original Message-
From: Christopher Kings-Lynne [mailto:[EMAIL PROTECTED]
Sent: Fri 6/17/2005 9:47 AM
To: Magnus Hagander
Cc: Dave Page; Josh Berkus; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Utility database (Was: RE: Autovacuum in the backend)
> In phpPgAdmin the defa
Probably, though the create db issue is a good reason not to use template1.
Create db issue?
So may I propose to have a pg_system database created by initdb, as a
copy from template1 in 8.1?
But then dbas will block off access to that db, or drop it and we're
back to square one...
Chris
Christopher Kings-Lynne wrote:
In phpPgAdmin the default db to connect to can be specified
per-server in the config file. It defaults to template1. It
actually is not relevant at all which db it is, so long as they can
connect to it.
I wonder how many users actually change that value for p
In phpPgAdmin the default db to connect to can be specified per-server
in the config file. It defaults to template1. It actually is not
relevant at all which db it is, so long as they can connect to it.
I wonder how many users actually change that value for php/pgadmin or
simply leave it def
Christopher Kings-Lynne wrote:
In phpPgAdmin the default db to connect to can be specified per-server
in the config file. It defaults to template1. It actually is not
relevant at all which db it is, so long as they can connect to it.
I wonder how many users actually change that value for
I think this is a very good idea. I've come up against this need once or
twice before.. And the fact that stuff in template1 gets propagated out
to all newly created databases can be a major pain when this happens.
A shared database for this stuff would be great - then each tool could
just create
Magnus Hagander wrote:
fer enhanced functionality in the client.
To overcome this, a alternative database created by initdb
would be very useful. This would be roughly the equivalent of
SQL Server's 'msdb'
database and would allow:
- A default non-template database for apps to connect to ini
I also think it is useful and make things easier.
A connection on template1 also prevent others to create new databases.
connection1:
template1#=
connection2:
foo=# create database bar;
ERROR: source database template1 is being accessed by other users
---(end of broad
> One related idea that I have been meaning to moot for a while
> now though, is that of a 'utility' database. One of the
> problems we've always had in pgAdmin (and presumably
> phpPgAdmin as well), is that the only database we know exists
> with any reasonable surety is template1, and consequ
> -Original Message-
> From: Josh Berkus [mailto:[EMAIL PROTECTED]
> Sent: 16 June 2005 17:29
> To: Dave Page
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Autovacuum in the backend
>
> Dave,
>
> > In previous discussions on -hackers when ppl raised the idea of
> > somet
35 matches
Mail list logo
