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

wieck(at)debis(dot)com (Jan Wieck) writes:
> Christof Petig and me then could start implementing it, using
> lztext with locally disabled compression feature for the
> basics. I'll not commit any changes until after feature
> freeze of the upcoming release. During the last changes (for
> HeapTuple handling) I've seen many places in the code, that
> deal themself on VARSIZE/VARDATA with text type attributes,
> which then must use textout() instead (what IMHO is better
> anyway). So implementing an ALL-varsize move off, instead of
> a special LONG datatype, will take longer than February 1st.

OK, I feel a lot better about planning this for next release instead
of the Feb-1 release.

It seems like what we ought to be doing in the near term is finishing
up the loose ends that remain with table locking, cache invalidation,
etc. The recently reported "LockRelease" errors seem to fall into
that category as well. Anyway, my point is we ought to go full steam
ahead into cleanup-and-make-ready-for-release mode. Dare I suggest
that we should declare feature freeze *now*, and concentrate on bug
fixes only for the next six weeks? If not, what features are on the
near horizon?

If Bruce wants to run pgindent before the Feb release, maybe the easiest
answer is to do it now (in the next few days) and then Jan can start
working on his new stuff without worrying about it.

regards, tom lane

> It seems like what we ought to be doing in the near term is finishing
> up the loose ends that remain with table locking, cache invalidation,
> etc. The recently reported "LockRelease" errors seem to fall into
> that category as well. Anyway, my point is we ought to go full steam
> ahead into cleanup-and-make-ready-for-release mode. Dare I suggest
> that we should declare feature freeze *now*, and concentrate on bug
> fixes only for the next six weeks? If not, what features are on the
> near horizon?
>
> If Bruce wants to run pgindent before the Feb release, maybe the easiest
> answer is to do it now (in the next few days) and then Jan can start
> working on his new stuff without worrying about it.

I don't need to run pgindent before _every_ release. No problem.

I don't see Jan's work chaning what the rest of us focus on. Let's see
how it goes. I certainly don't have anything planned.

--
Bruce Momjian | http://www.op.net/~candle
maillist(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

On 1999-12-18, Tom Lane mentioned:

> ahead into cleanup-and-make-ready-for-release mode. Dare I suggest
> that we should declare feature freeze *now*, and concentrate on bug
> fixes only for the next six weeks? If not, what features are on the
> near horizon?

What would be the difference between a feature-freeze and a beta then? I'm
sure every sane developer wouldn't start anything completely new right now
but I for my part still see up to a handful of TODO items that could be
fixed with two nights' work each.

--
Peter Eisentraut Sernanders väg 10:115
peter_e(at)gmx(dot)net 75262 Uppsala
http://yi.org/peter-e/ Sweden

On 1999-12-18, Bruce Momjian mentioned:

> I don't need to run pgindent before _every_ release. No problem.

Is this pgindent thing negotiable at all? IMHO the output of plain indent
-orig looks much nicer (and readable). It also tends to look like the bsd
c-style in emacs. If we could just tell people 'set up {emacs|vi|ed} like
this' (such as c-set-style bsd) there wouldn't be half a dozen different
formats propagating through the source until someone comes around with
pgindent.

Btw., I use GNU indent 2.2.1 which is a long way from the versions
pgindent tries to warn about.

More important than arguing about code formatting, however: Could we lose
this a-tab-looks-like-4-spaces thing, now that Bruce has a new editor(?) ?
In any unprepar{ed|able} viewer (cat/more/less/pico) the code looks like
hell. Maybe we could lose the tab altogether because it's a pain. Just
insert 4 (8, 12, ...) spaces.

--
Peter Eisentraut Sernanders väg 10:115
peter_e(at)gmx(dot)net 75262 Uppsala
http://yi.org/peter-e/ Sweden

[Charset ISO-8859-1 unsupported, filtering to ASCII...]
> On 1999-12-18, Bruce Momjian mentioned:
>
> > I don't need to run pgindent before _every_ release. No problem.
>
> Is this pgindent thing negotiable at all? IMHO the output of plain indent
> -orig looks much nicer (and readable). It also tends to look like the bsd
> c-style in emacs. If we could just tell people 'set up {emacs|vi|ed} like
> this' (such as c-set-style bsd) there wouldn't be half a dozen different
> formats propagating through the source until someone comes around with
> pgindent.

I did not decide on this format myself, but several developers said they
prefer this format, and I do too. I am willing to open the discussion
to see what people would prefer.

The current format does match my C style for non-PostgreSQL projects
too.

I remember clear mention that we did not like:

if () {

}

I see you are writing your shell scripts with that, and am not a fan of
it, but it is only a shell script.

>
> Btw., I use GNU indent 2.2.1 which is a long way from the versions
> pgindent tries to warn about.

Yes, the message was from when GNU indent had stoppped development in
1994 or so, and they bugs never had been fixed. I have no idea how the
new GNU indent is. I am sure it has fixed some of the older bugs, but I
don't know if they added new bugs.

>
> More important than arguing about code formatting, however: Could we lose
> this a-tab-looks-like-4-spaces thing, now that Bruce has a new editor(?) ?
> In any unprepar{ed|able} viewer (cat/more/less/pico) the code looks like
> hell. Maybe we could lose the tab altogether because it's a pain. Just
> insert 4 (8, 12, ...) spaces.

Again, I think everyone liked it at the time, but this may have changed.

Speak up, folks.

--
Bruce Momjian | http://www.op.net/~candle
maillist(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

On 18-Dec-99 Bruce Momjian wrote:
> [Charset ISO-8859-1 unsupported, filtering to ASCII...]
>
> I remember clear mention that we did not like:
>
> if () {
>
> }

Figures. that's the only method I do like!

Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev(at)michvhf(dot)com http://www.pop4.net
128K ISDN - $24.95/mo or less; 56K Dialup - $17.95/mo or less www.pop4.net
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================

On 1999-12-18, Bruce Momjian mentioned:

> I remember clear mention that we did not like:
>
> if () {
>
> }
>
> I see you are writing your shell scripts with that, and am not a fan of
> it, but it is only a shell script.

What do I know about shell scripting? :)

Seriously though, I didn't use to do that, but I get to like it more every
day ... I was going to look for an example of uglily-formatted code now,
but can't find one. My concern was more about the 4-space-tabs, because a
tab is 8 spaces in the rest of the world. I have no problem with 4 space
indentation and the good old bsd format.

--
Peter Eisentraut Sernanders väg 10:115
peter_e(at)gmx(dot)net 75262 Uppsala
http://yi.org/peter-e/ Sweden

[Charset ISO-8859-1 unsupported, filtering to ASCII...]
> On 1999-12-18, Bruce Momjian mentioned:
>
> > I remember clear mention that we did not like:
> >
> > if () {
> >
> > }
> >
> > I see you are writing your shell scripts with that, and am not a fan of
> > it, but it is only a shell script.
>
> What do I know about shell scripting? :)
>
> Seriously though, I didn't use to do that, but I get to like it more every
> day ... I was going to look for an example of uglily-formatted code now,
> but can't find one. My concern was more about the 4-space-tabs, because a
> tab is 8 spaces in the rest of the world. I have no problem with 4 space
> indentation and the good old bsd format.

As a workaround, there is a C program I wrote called entab in
pgsql/src/tools/entab. It has a manual page and everything. It does a
good job of converting tabs to any size, or removing all tabs. It does
certain fancy things like prevent tab changes inside quoted strings, and
clip trailing whitespace. That is what I do in my print filters.

I admit our current system is a pain. Our options are:

o go to 8 space tabs and 8 space indenting
o go to 8 space tabs and 4 space indenting
o keep 4 space tabs and 4 space indenting

The first option is out. Eight space indenting is a pain, and our code
would look terrible. Eight is just too much and prevents meaningful
indenting.

The second option is your preference. It is easier to print, but
editing the file can be a pain for editors that don't support
different tab/indent values. Also, I like cursoring over tabs, so
having some indents as 4 spaces and some as full tabs give the code a
funny feeling for me.

I print a lot less, and use entab do handle the 4-space issue, so it
seems the best for me.

--
Bruce Momjian | http://www.op.net/~candle
maillist(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

Tom Lane wrote:

> Dare I suggest
> that we should declare feature freeze *now*, and concentrate on bug
> fixes only for the next six weeks? If not, what features are on the
> near horizon?

Only if the implementation of the temp file buffered deferred
trigger event queue isn't considered a feature, and after I
committed the catalog changes I need to go on with LONG
quietly.

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

Bruce Momjian wrote:

> > If Bruce wants to run pgindent before the Feb release, maybe the easiest
> > answer is to do it now (in the next few days) and then Jan can start
> > working on his new stuff without worrying about it.
>
> I don't need to run pgindent before _every_ release. No problem.
>
> I don't see Jan's work chaning what the rest of us focus on. Let's see
> how it goes. I certainly don't have anything planned.

Would be best for me if you can leave out the pgindent run
for this release. I already have some small things as
patches, that I apply to the latest cvs update. And I fear
what's currently discussed about changing 4 column tabstops
would break them completely.

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

> Bruce Momjian wrote:
>
> > > If Bruce wants to run pgindent before the Feb release, maybe the easiest
> > > answer is to do it now (in the next few days) and then Jan can start
> > > working on his new stuff without worrying about it.
> >
> > I don't need to run pgindent before _every_ release. No problem.
> >
> > I don't see Jan's work chaning what the rest of us focus on. Let's see
> > how it goes. I certainly don't have anything planned.
>
> Would be best for me if you can leave out the pgindent run
> for this release. I already have some small things as
> patches, that I apply to the latest cvs update. And I fear
> what's currently discussed about changing 4 column tabstops
> would break them completely.

Got it, no pgindent run.

--
Bruce Momjian | http://www.op.net/~candle
maillist(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

wieck(at)debis(dot)com (Jan Wieck) writes:
> Tom Lane wrote:
>> Dare I suggest that we should declare feature freeze *now*,

> Only if the implementation of the temp file buffered deferred
> trigger event queue isn't considered a feature,

It's obviously a necessary fix. But no one seemed excited about an
early feature freeze anyway, so disregard that comment...

regards, tom lane

wieck(at)debis(dot)com (Jan Wieck) writes:
> Would be best for me if you can leave out the pgindent run
> for this release. I already have some small things as
> patches, that I apply to the latest cvs update.

Why not do what Vadim is doing for XLOG: commit your changes under
#ifdefs for a symbol that isn't yet defined?

#ifdef LONG_ATTRS
new code
#else
old code
#endif

I think this'd possibly be helpful anyway for study and debugging
purposes, since people could easily see what you've changed and where.
Eventually, after all the dust settles, we can get rid of the #if's
and the old-code fragments.

I don't normally like #ifdef'd patches of this sort, but as a temporary
measure during implementation I think it'd be better than keeping a
private set of files.

> And I fear
> what's currently discussed about changing 4 column tabstops
> would break them completely.

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.

regards, tom lane

> wieck(at)debis(dot)com (Jan Wieck) writes:
> > Tom Lane wrote:
> >> Dare I suggest that we should declare feature freeze *now*,
>
> > Only if the implementation of the temp file buffered deferred
> > trigger event queue isn't considered a feature,
>
> It's obviously a necessary fix. But no one seemed excited about an
> early feature freeze anyway, so disregard that comment...

Yes, Tom, I was wondering about your early freeze proposal. If we
freeze, we may as well start beta. However, I believe it was you who
suggested Feb 1 rather than Jan 1 because you wanted to clean up some
things.

So, I assume we are scheduled for a Feb 1 beta, and anything Jan can get
done by then should be added, including any working implementation of
foreign keys or long tuples.

It doesn't have to be 100% tested, just working. Testing is for the beta
period. And Jan, others are ready to assist you. I didn't understand
foreign keys, but I think I have an idea about long tuples.

--
Bruce Momjian | http://www.op.net/~candle
maillist(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

> wieck(at)debis(dot)com (Jan Wieck) writes:
> > Would be best for me if you can leave out the pgindent run
> > for this release. I already have some small things as
> > patches, that I apply to the latest cvs update.
>
> Why not do what Vadim is doing for XLOG: commit your changes under
> #ifdefs for a symbol that isn't yet defined?
>
> #ifdef LONG_ATTRS
> new code
> #else
> old code
> #endif
>
> I think this'd possibly be helpful anyway for study and debugging
> purposes, since people could easily see what you've changed and where.
> Eventually, after all the dust settles, we can get rid of the #if's
> and the old-code fragments.

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.

However, he may be able to get to a point with his new macros that he
can commit the changes and have long handling turned off until he is
happy with it. That would be nice so we can test it by just changing
the macro.

>
> I don't normally like #ifdef'd patches of this sort, but as a temporary
> measure during implementation I think it'd be better than keeping a
> private set of files.
>
> > And I fear
> > what's currently discussed about changing 4 column tabstops
> > would break them completely.
>
> 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.

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.

--
Bruce Momjian | http://www.op.net/~candle
maillist(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

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

> 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.

Good.

>
> 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.

OK, that tips the scales in favor of 8-char tabs. My micro-emacs can't
handle different indent and tab sizes, but that is an old non-X-based
editor. I then checked Crisp, my new X editor, and I can't see how to
that either.

However, I don't do that much coding, so if people want to go for 8-byte
tabs and 4-byte indent, we can do that.

Any objections on for that?

> 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.

Let me know.

--
Bruce Momjian | http://www.op.net/~candle
maillist(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026