Re: [HACKERS] LONG varsize - how to go on - Mailing list 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@debis.com (Jan Wieck) #