Hi,
I tried to backport Simon Riggs patches for 7.4.x series to 7.3.x
with addition of python implementation of pg_arch.
It can be of interest if you consider to continue using 7.3 series of postgresql.
src/backend/access/transam/xlog.c: calls to "ereport" was replaced with call to
"elog".
src
Duh, sorry. Got confused. I though you weren't the submitter, for some
strange reason. Anyway, I see this in the code:
+ /* Handle array types */
+ if (typname[0] == '_')
+ {
+ isarray = true;
+ typname++;
+ }
Do we know that is always true? What is th
Christopher Kings-Lynne wrote:
> >>I submitted a fix for 7.5 dumping 7.0 previously and it was accepted :)
>
> That previous fix was for a different issue...
>
> > Oh, it for using a 7.5 dump on a 7.0 database? I didn't think that
> > would even work. :-)
>
> Yes, it works fine. We still sup
I submitted a fix for 7.5 dumping 7.0 previously and it was accepted :)
That previous fix was for a different issue...
Oh, it for using a 7.5 dump on a 7.0 database? I didn't think that
would even work. :-)
Yes, it works fine. We still support pg_dumping all 7.x databases.
Anyway, you say the f
Christopher Kings-Lynne wrote:
> No, the patch is against 7.5 CVS. It is a tiny fix that allows it to
> dump 7.0.x database backends correctly.
>
> I submitted a fix for 7.5 dumping 7.0 previously and it was accepted :)
Oh, it for using a 7.5 dump on a 7.0 database? I didn't think that
would e
Fabien COELHO wrote:
Dear Alvaro,
> (2) bitwise integer aggregates named bit_and and bit_or for
> int2, int4, int8 and bit types. They are not standard,
> however they exist in other db (eg mysql), and I needed them
> for some other stuff.
I'm sure people won't like to add functions jus
No, the patch is against 7.5 CVS. It is a tiny fix that allows it to
dump 7.0.x database backends correctly.
I submitted a fix for 7.5 dumping 7.0 previously and it was accepted :)
Chris
Bruce Momjian wrote:
Uh, not sure anyone would even see a 7.0.X release if we made it, and I
question how man
Uh, not sure anyone would even see a 7.0.X release if we made it, and I
question how many are using varying[]. Your patch is now in the
archives, and we can point folks to it if they ask.
---
Christopher Kings-Lynne wrote:
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > Tom Lane wrote:
> > > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > > Ouch. How long has that documentation been wrong? We have
> > > > pointed folks to that section of the docs tons of times, and no
> > > > one mentioned that "logrotate" is re
Neil Conway <[EMAIL PROTECTED]> writes:
> On Fri, 2004-05-14 at 17:40, Alvaro Herrera wrote:
>> Turns out the patch is too big and the server won't publish it.
> Is there a good reason for keeping this size limit on the -patches list?
I think Marc was more or less forced into lowering the size li
On Sat, 2004-05-15 at 11:52, Tom Lane wrote:
> But the spec hasn't even got log(), so it can hardly be thought to be
> taking a position on what error codes log() should return. I think
> log() should use the same error codes as ln().
Point taken, I've made this change.
> You might consider chan
On Sat, May 15, 2004 at 05:45:00PM -0400, Neil Conway wrote:
> On Fri, 2004-05-14 at 13:14, David Fetter wrote:
> > Pursuant to suggestions.
>
> I've attached the version of this patch I intend to apply as soon as
> CVS is back up.
>
> Thanks for the patch, David.
And thank you for all the help
Hi,
I know 7.0.x is pretty old, but I'm wondering if we should fix this to
make it better for people upgrading.
If you create a table like this in 7.0.x:
CREATE TABLE address (
first_name character varying(50) DEFAULT 'asdf' NOT NULL,
last_name character varying(50) NOT NULL,
address
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > Ouch. How long has that documentation been wrong? We have
> > > pointed folks to that section of the docs tons of times, and no
> > > one mentioned that "logrotate" is really "rotatelogs", and that
> > > it
14 matches
Mail list logo
