Simon Riggs wrote:
Now we're into 8.2devel mode, its time to submit the previously
discussed patch that:
- reduces Numeric storage format by 2 bytes
This makes the often discussed binary upgrade impossible, so I wonder if
two bytes savings are worth the trouble.
Regards,
Andreas
Hi,
Here is my patch to make psql handle multi-line output sanely. Instead
of embedded newlines splattering your output across the screen,
everything gets indented to the right column.
It basically works by extending the *_width functions to instead work
out the estimate width, height and
Christopher Kings-Lynne wrote:
I think anything else will have to be done individually, although the
pattern can be copied.
Perhaps we should take bids on what should/should not be covered.
Everything should be covered, otherwise it's just annoying for users...
Well, that's arguably
Andreas Pflug [EMAIL PROTECTED] writes:
Simon Riggs wrote:
Now we're into 8.2devel mode, its time to submit the previously
discussed patch that:
- reduces Numeric storage format by 2 bytes
This makes the often discussed binary upgrade impossible, so I wonder if
two bytes savings are worth
Tom Lane wrote:
Andreas Pflug [EMAIL PROTECTED] writes:
Simon Riggs wrote:
Now we're into 8.2devel mode, its time to submit the previously
discussed patch that:
- reduces Numeric storage format by 2 bytes
This makes the often discussed binary upgrade impossible, so I wonder if
two bytes
Hm, so if this patch is applied now, and in 5 months or so somebody
implements pg_upgrade, this numeric storage patch would be rolled back?
OTOH, an upgrade mechanism that's compatible for future 8.3+ versions
only seems not too attractive.
With Slony and Replicator I don't really see the
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Joshua D. Drake
Sent: 17 November 2005 15:58
To: Andreas Pflug
Cc: Tom Lane; Simon Riggs; pgsql-patches@postgresql.org
Subject: Re: [PATCHES] Numeric 508 datatype
Hm, so if this patch is
Joshua D. Drake wrote:
With Slony and Replicator I don't really see the need for in place
upgrades.
Maintaining a replica is hardly a cost-free exercise.
However, I don't think we can promise never to change the ondisk
representation of data, nor the page layout. Sometimes an inplace
Andrew Dunstan [EMAIL PROTECTED] writes:
However, I don't think we can promise never to change the ondisk
representation of data, nor the page layout. Sometimes an inplace
upgrade just won't work, ISTM.
We have talked about batching on-disk changes so that they'd only occur
once every few
On Thu, 2005-11-17 at 11:20 -0500, Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
However, I don't think we can promise never to change the ondisk
representation of data, nor the page layout. Sometimes an inplace
upgrade just won't work, ISTM.
We have talked about batching
Simon Riggs [EMAIL PROTECTED] writes:
If the patch is accepted technically, in can be applied at any time,
right up to code freeze for this or the next release. It's a fairly
independent patch.
I'd suggest we check it out now, then put it in a holding pen for awhile
to see if an upgrade tool
They're not exactly easy to setup for the casual user (well, I assume
replicator isn't but it's not relevant to the majority of our users
anyway).
Well FYI any half way competent person can set up replicator in 30
minutes or less ;), that said
in place upgrades are a feature that will take
On Nov 17, 2005, at 11:51 , Christopher Kings-Lynne wrote:
Including objects that already have CREATE OR REPLACE?
I assume so - CREATE OR REPLACE doesn't drop things - only creates
or replaces them.
Of course. Silly me :)
Michael Glaesemann
grzm myrealbox com
Minor comment update.
The line changed is in direct contradiction with the comment (and
reality) of the code below this. The opposed comment starts at line
1548:
/*
* Note: Normally one would think that we have to delete index tuples
* associated with the heap tuple now..
*
* ... but in
If the consensus is to add this to all of them, then I propose to apply
the patch I have (with a slight fix for an oversight in the case of
domains, plus docs and tests) for the 8 cases and start working on the
remaining 13 as time permits. To be honest, I have not even looked at
those 13
Simon Riggs wrote:
I like this, but not because I want to read it myself, but because I
want to make autovacuum responsible for re-allocating free space when it
runs out. This way we can have an autoFSM feature in 8.2
Not wanting to denigrate value of the interesting but slightly OT
16 matches
Mail list logo
