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 th
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 Networ
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 rea
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
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
Ü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 r
"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
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 t
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 re
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
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 Fri, Dec 09, 2005 at 11:32:48AM -0500, Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian 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 we do enou
>>> 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
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
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 re
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
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 us
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
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 -r
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, 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, ra
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
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
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
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
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'
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 t
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 o
28 matches
Mail list logo
