Tuple toaster (was: Re: LONG varsize - how to go on) - Mailing list pgsql-hackers

From wieck@debis.com (Jan Wieck)
Subject Tuple toaster (was: Re: LONG varsize - how to go on)
Date
Msg-id m120C3U-0003kHC@orion.SAPserv.Hamburg.dsh.de
Whole thread Raw
In response to Re: [HACKERS] LONG varsize - how to go on  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: [HACKERS] Tuple toaster (was: Re: LONG varsize - how to go on)
List pgsql-hackers
Bruce Momjian wrote:

> I think Vadim had a single entry point that he could control in that
> way.  Not sure Jan has such an entry point.  If the stuff goes all over
> the place, #ifdef can be hard to read as you are coding.

    Sure,  there will be some more entry points this time. But as
    far as I see up to now, not too many in  the  beginning.  And
    for storing values, they're all located in heapam.c.

    Since  we decided not to create a separate LONG datatype, and
    not doing LONG attributes alone (compression  at  some  point
    too),  I  looked for some unique name for it - and found one.
    The characters 'toast' did not show up on a case  insensitive
    grep over the entire CVS tree. Thus, I'll call it

        tuple toaster

    subsequently.  I  think  there  are  enough similarities to a
    toaster in this case. If you take a bread (tuple)  and  toast
    some  of  the  slices  (attributes), anything can work as you
    want and it will smell and taste delicious.  In  some  cases,
    slices  might  get  burned  (occationally  hitting an indexed
    value), taste bitter and it will stink.

    BTW: The idea itself was stolen  from  toast/untoast,  a  GSM
    voice data compression/decompression tool.

    I'll commit some more changes that put in the basics #ifdef'd
    out soon.

> > Bruce doesn't want to do that, and I doubt anyone will force the issue
> > over his veto.  But it would be nice to be able to do a pgindent run;
> > there's a lot of new code in this release.
>
> I hope I didn't "veto" it.  I just wanted to mention my reasons, and
> look for other people to vote too.  I have Vince, Peter, and Tom who
> want 8-space tabs and 4-space indents.  Because the old standard was
> voted on by many more people, I need to hear additional votes to change
> our standard.

    Who uses an editor that cannot  distinguish  between  tabstop
    and shiftwidth? And which editors are these - are they useful
    for programming at all?

    Anyway, I vote for 8-space tabs and 4-space indents  too.  My
    .exrc  set's  up  4-space tabs actually, and it's a real mess
    when editing non-PG sources.

> Jan, can we run a pgindent on the current sources with the current tab
> size unchanged?  I don't think that would affect you very much.
> However, I can wait until most of your code is committed.  I don't
> normally run pgindent until just before the final release date.

    You can do anything you want soon. I intend only to  put  the
    #ifdef'd out calls to the toaster into heapam.c, and create a
    new  tuptoaster.c  in  the  same  location,  again  all  code
    #ifdef'd  out. From then on, I can work CVS based without any
    interference.


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) #

pgsql-hackers by date:

Previous
From: Lamar Owen
Date:
Subject: Re: [HACKERS] SPI Headers -- RPM distribution
Next
From: wieck@debis.com (Jan Wieck)
Date:
Subject: LONG vs. Toaster