Tuple toaster (was: Re: 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: tgl(at)sss(dot)pgh(dot)pa(dot)us, wieck(at)debis(dot)com, pgsql-hackers(at)postgreSQL(dot)org
Subject: Tuple toaster (was: Re: LONG varsize - how to go on)
Date: 1999-12-20 23:17:28
Message-ID: m120C3U-0003kHC@orion.SAPserv.Hamburg.dsh.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)debis(dot)com (Jan Wieck) #

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jan Wieck 1999-12-20 23:37:02 LONG vs. Toaster
Previous Message Lamar Owen 1999-12-20 21:46:50 Re: [HACKERS] SPI Headers -- RPM distribution