Re: [HACKERS] LONG varsize - how to go on

From: wieck(at)debis(dot)com (Jan Wieck)
To: pgman(at)candle(dot)pha(dot)pa(dot)us (Bruce Momjian)
Cc: wieck(at)debis(dot)com, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] LONG varsize - how to go on
Date: 1999-12-17 23:24:13
Message-ID: m11z6jN-0003kKC@orion.SAPserv.Hamburg.dsh.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> Setting the compress bit to catch any unusual cases may be interesting,
> though I can't see how any routine could get to the varlena data without
> accessing the field name or macros.

Take a look at NUMERIC or LZTEXT types (both by me and thus I
knew) and you'll know. That's what I meant with implicit
casting.

> I am concerned about your trying to continue development on a snapshot
> while we release the 7.0 release. A single pgindent run will mess you
> up terribly. I can prevent that, but other work will affect you.

Oh - yes! Please don't do a pgindent.

Otherwise it's relatively simple if you know how (screwed up)
I usually work.

First of all, I only use a very limited set of actions while
I'm in my checked out CVS working directory:

cvs update
patch <... (and remove .orig files)
cvs commit

To do a hack, I copy the entire CVS working dir to another
location, configure it and save another copy of the
configured sources into a .orig tree. Then I start hacking,
and if something useful falls out finally, there are two
possible ways depending on the time, the 'hacking' step took:

1. Short (less than 4 hours)
I apply the patch to my CVS working directory and commit
it.

2. Long
I do a 'cvs update', take a copy of it and try to apply
my own patch to that. If it works well down to the
regression test, I can use this patch to apply it to CVS,
otherwise, I need to fix, rediff and start over at 2.

To stay in sync with CURRENT during a long time hack, I just
have to do this:

- Every some days, take a diff of my so far done changes,
- do a 'cvs update',
- take a fresh copy of the CURRENT tree
- and apply my patch onto it.

The last step might show up some rejected hunks, resulting
from conflicting changes by others. Or it might cause other
errors due to conflicts, patch cannot detect. But if doing
these steps frequently enough, the efford to stay in sync
with CURRENT is relatively low.

Someone might think that's a very expensive way of
developing. But over the years, I had good success on long
term hacks with it. And since some folks seem not to agree
with my point of view about using CVS branching for long term
development, it's the only way for me to do it in a similar
way (saving intermediate states of my patches also gives me
the power to start over on an earlier stage).

I assume, some people lost me during the description. But
anyway, I use this for a couple of years now, and it works
fine.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck(at)debis(dot)com (Jan Wieck) #

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Hiroshi Inoue 1999-12-17 23:30:54 RE: [HACKERS] NOTICE: LockRelease: locktable lookup failed, no lock
Previous Message Tom Lane 1999-12-17 23:18:08 Mail list archive search busted?