Hi,
At my work, I have to dump a database and restore it on another database under
a specific schema. My first idea was to create the new schema on the old
database, move all the database objects on this new schema, dump the old db
and restore on the new one. But I have to move quite a lot of
On Dec 08 04:36, Kai wrote:
After working regularly with inet values in sql, it would be nice to be able
to do this:
= select '192.168.1.1'::inet + 1 as result;
result
-
192.168.1.2
(1 row)
You may take a look at ip4r[1] project too. For
Hello,
On Fri, 2005-12-09 at 08:47 -0500, Christopher Browne wrote:
We *know* (particularly those of us that have had involvement in
actually implementing replication systems used in production
environments) that user space implementations of replication can
function satisfactorily. We've
On Fri, 2005-12-09 at 12:32 -0500, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
My proposal to solve that problem, is to make any transaction that
inserts or modifies tuples in a table that is marked as frozen, unfreeze
it first. The problem I had last time was finding a good
On Fri, 2005-12-09 at 19:41 +0100, Peter Eisentraut wrote:
Tom Lane wrote:
As I said already, if the user wishes the password to be secure, he
needs to encrypt it on the client side.
Maybe we should provide a backslash command in psql
That is a good option, but not the only option
We have a patch for this for application to 8.2.
---
Volkan YAZICI wrote:
On Dec 08 04:36, Kai wrote:
After working regularly with inet values in sql, it would be nice to be able
to do this:
= select
Simon Riggs wrote:
From what's been said VACUUM FREEZE will not alter the fact that a
frozen table will need vacuuming again in the future and so cannot ever
be read-only. I can't really see any reason to run VACUUM FREEZE...
Yeah.
If you want to make a table read-only forever, we need a
Simon Riggs [EMAIL PROTECTED] writes:
On Fri, 2005-12-09 at 19:41 +0100, Peter Eisentraut wrote:
Maybe we should provide a backslash command in psql
That is a good option, but not the only option required.
There are many reasons to need to supply the password as part of a
command, rather
I've just uploaded pgInstaller 8.1.1 - it should be at
http://ftp.postgresql.org/pub/binary/v8.1.1/binary/win32 within an hour
or so. Please take a peek as soon as possible if you have a Windows box
and report any problems before any announcements go out.
This include PostgreSQL 8.1.1 of course,
Guillaume LELARGE [EMAIL PROTECTED] writes:
Apparently, I can rename all schemas, even system schemas !
metier=# alter schema pg_catalog rename to foobar;
ALTER SCHEMA
If you are superuser, you can do anything you want, up to and including
breaking the system irretrievably. Compare rm -rf /
Tom Lane wrote:
If you are superuser, you can do anything you want, up to and including
breaking the system irretrievably. Compare rm -rf / on Unix. We
won't be putting training wheels on superuser status for the same
reasons that no one finds it a good idea to restrict root's abilities.
Alvaro Herrera [EMAIL PROTECTED] writes:
However there is an effort to get rid of root in some Unix lands,
separating its responsabilities with more granularity. Maybe there
could be an effort, not to hand-hold the true superusers, but to
delegate some of its responsabilities to other users.
However there is an effort to get rid of root in some Unix lands,
separating its responsabilities with more granularity. Maybe there
could be an effort, not to hand-hold the true superusers, but to
delegate some of its responsabilities to other users.
Like sudo?
Joshua D. Drake
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
However there is an effort to get rid of root in some Unix lands,
separating its responsabilities with more granularity. Maybe there
could be an effort, not to hand-hold the true superusers, but to
delegate some of its
Joshua D. Drake wrote:
However there is an effort to get rid of root in some Unix lands,
separating its responsabilities with more granularity. Maybe there
could be an effort, not to hand-hold the true superusers, but to
delegate some of its responsabilities to other users.
Like sudo?
I
On Fri, Dec 9, 2005 at 11:24 am, in message
[EMAIL PROTECTED], Peter Eisentraut
[EMAIL PROTECTED] wrote:
Kevin Grittner wrote:
direction PostgreSQL is headed is to drop the nonstandard escapes,
unless an extended literal is explicitly used. I've attached a
patch
which supports this as a
On Fri, Dec 09, 2005 at 11:32:48AM -0500, Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
I can see that being useful for a single-user application that doesn't
have locking or I/O bottlenecks, and doesn't have a multi-stage design
like a database. Do
Like sudo?
I was thinking in the thing called capabilities.
I just meant as a metaphor ;)
--
Command Prompt, Inc., Your PostgreSQL solutions company. 503-667-4564
Custom programming, 24x7 support, managed services, and hosting
Open Source Authors: plPHP, pgManage, Co-Authors: plPerlNG
On Sat, Dec 10, 2005 at 14:25:46 -0300,
Alvaro Herrera [EMAIL PROTECTED] wrote:
Joshua D. Drake wrote:
However there is an effort to get rid of root in some Unix lands,
separating its responsabilities with more granularity. Maybe there
could be an effort, not to hand-hold the true
On Sat, 2005-12-10 at 11:15 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Fri, 2005-12-09 at 19:41 +0100, Peter Eisentraut wrote:
Maybe we should provide a backslash command in psql
That is a good option, but not the only option required.
There are many reasons to
Was thinking if someone could summarize this all it would make a really good
FAQ entry.
Robert Treat
On Friday 09 December 2005 13:28, Martijn van Oosterhout wrote:
On Fri, Dec 09, 2005 at 12:38:21PM -0500, Bruce Momjian wrote:
This means someone who is planning on upgrading to 8.1 in two
Simon Riggs [EMAIL PROTECTED] wrote
You may be trying to use the memory too early. Prefetched memory takes
time to arrive in cache, so you may need to issue prefetch calls for N
+2, N+3 etc rather than simply N+1.
p.6-11 covers this.
I actually tried it and no improvements have been
Ühel kenal päeval, N, 2005-12-08 kell 14:53, kirjutas Tom Lane:
Given the discussion so far, it seems likely to me that completely
concurrent REINDEX is indeed out of reach, and that what we ought to
be thinking about is what sort of compromise design (ie, partially
concurrent REINDEX) is
Kevin Grittner wrote:
On Fri, Dec 9, 2005 at 11:24 am, in message
[EMAIL PROTECTED], Peter Eisentraut
[EMAIL PROTECTED] wrote:
Kevin Grittner wrote:
direction PostgreSQL is headed is to drop the nonstandard escapes,
unless an extended literal is explicitly used. I've attached a
patch
Hannu Krosing [EMAIL PROTECTED] writes:
How do you plan to determine any rows not already present in the index
without explicitly remembering the start and end snapshots of existing
CREATE INDEX (SNAP1 and SNAP2 in my proposal)?
I was thinking in terms of actually looking into the index to see
I don't see it asked very often, and I think our 8.1 releae note
addition (plus a mention in the 8.1.1 notes) will complete this.
---
Robert Treat wrote:
Was thinking if someone could summarize this all it would make a
7.3.12, 7.4.10, 8.0.5 and 8.1.1 ... all should be available on the ftp
mirrors by now ... please take a quick peak at them, and let us know if
there appear to be any problems with them ...
General announce of availability going out on monday ...
Marc G. Fournier Hub.Org
Bruce Momjian wrote:
I don't see it asked very often, and I think our 8.1 releae note
addition (plus a mention in the 8.1.1 notes) will complete this.
Actually a upgrade FAQ is probably a good idea. Something that says
what really happens
when foo changes in 8.1 or how foo is different
28 matches
Mail list logo
