Re: [HACKERS] PostgreSQL 6.5.2 - Mailing list pgsql-hackers
From | Massimo Dal Zotto |
---|---|
Subject | Re: [HACKERS] PostgreSQL 6.5.2 |
Date | |
Msg-id | 199909032027.WAA02488@nikita.wizard.net Whole thread Raw |
In response to | Re: [HACKERS] PostgreSQL 6.5.2 (Bruce Momjian <maillist@candle.pha.pa.us>) |
Responses |
Re: [HACKERS] PostgreSQL 6.5.2
|
List | pgsql-hackers |
> > On Tue, 31 Aug 1999, Tom Lane wrote: > > > > > Massimo Dal Zotto <dz@wizard.net> writes: > > > > May I ask that the patches I submitted two months ago for 6.5.0 are applied > > > > at least to 6.5.2? > > > > Here is the 6.5.1 version of my patches. > > > > > > I don't much care for QueryLimit (we got rid of that for a reason!) > > > nor for the FREE_TUPLE_MEMORY patch, but the rest of this looks safe > > > enough... but are we in the business of adding features to 6.5.*, > > > even little ones? Maybe it should only go in current. > > > > 6.5.x is supposed to be *only* fixes, no new features...but I'm curious as > > to why these never got into v6.5.0 in the first place... > > > > I applied the safe ones, like the copy.c one. People objected to most > of the others, for reasons I have forgotten. Most objections were beacause they were submitted just before the release date of 6.5.0. Now three months have passed. Which were the unsafe pathes? If an unsafe patch is one that can break some essential piece of code I would classify them in the following way: array safe, important bug fix to my contrib contrib safe, changes to makefiles in my contrib copy-cancel-query safe, it can't break anything unless you hit ^C emacs-vars safe, only cosmetic changes required by emacs20 free-tuple-mem safe, it is under #ifdef and disabled by default. I won't recommend enabling it in a production environment, but it could be the solution of many headaches for some people, like my old sinval patch. psql-readline safe, it just sets a readline documented variable set-variable mostly safe, except the queryLimit stuff which can be removed if you don't trust it. Thepg_options variable can be set only by the superuser. If you don't like the queryLimit stuff I can send you a new patch for the pg_options variable only. -- Massimo Dal Zotto +----------------------------------------------------------------------+ | Massimo Dal Zotto email: dz@cs.unitn.it | | Via Marconi, 141 phone: ++39-0461534251 | | 38057 Pergine Valsugana (TN) www: http://www.cs.unitn.it/~dz/ | | Italy pgp: finger dz@tango.cs.unitn.it | +----------------------------------------------------------------------+
pgsql-hackers by date: