How I would like to go on:

    What I've done so far is to prepare the HeapTuple handling so
    it should be possible to  reallocate  the  t_data  part  from
    inside the heap_insert() and heap_update().

    Next  would  be to define how the runtime configuration is to
    be stored and configured. So I can get at least  the  minimum
    required  system  catalog  changes made soon. If we leave out
    auto-compression for now, a rellongrelid  (type  Oid  default
    Invalid)  in  pg_class,  and  a attcanlong (type bool default
    true) in pg_attribute would do it. This would give  space  to
    enable  a  single relation for this feature, and then disable
    single columns again. New utility commands will finally  gain
    access  to  the  features.  Some  scripts  will  do it during
    development, so the feature will not show up  -  thus  beeing
    silently  unavailable to the user - until we want to ship it.

    I think these are the best places to  put  the  configuration
    into,  because  the information would be already available at
    no cost inside  heap  access  (rel->rd_rel->rellongrelid  and
    rel->rd_att...).

    What  I  want  to  implement  for  now,  is to store extended
    VARLENA  attributes  into  a  regular  (but  other   relkind)
    relation  with  the  Oid  key  as discussed.  That will cause
    minimum changes to VACUUM. If storage/retrieval of attributes
    is  encapsulated  right,  it  could get replaced by something
    different at any time in  the  future  when  we  have  enough
    experience with this new technique.

    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.

    This plan means in summary:

    1.  Full  possible  configurability  with   minimum   catalog
        changes.

    2.  Hidden  without any side effects until we agree to enable
        it.

    3.  Later optimizable storage of extended attributes.

    I can't see any reason to way much longer. Can we please have
    a consensus to get started?


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



Fri, 17 Dec 1999 11:59:50 +0100 (MET)
wieck@debis.com (Jan Wieck)
LONG varsize - how to go on
> How I would like to go on:
> 
>     What I've done so far is to prepare the HeapTuple handling so
>     it should be possible to  reallocate  the  t_data  part  from
>     inside the heap_insert() and heap_update().

OK, I assume this is so you can change the tuple size on the fly when
inserting the tuple.

> 
>     Next  would  be to define how the runtime configuration is to
>     be stored and configured. So I can get at least  the  minimum
>     required  system  catalog  changes made soon. If we leave out
>     auto-compression for now, a rellongrelid  (type  Oid  default
>     Invalid)  in  pg_class,  and  a attcanlong (type bool default
>     true) in pg_attribute would do it. This would give  space  to
>     enable  a  single relation for this feature, and then disable
>     single columns again. New utility commands will finally  gain
>     access  to  the  features.  Some  scripts  will  do it during
>     development, so the feature will not show up  -  thus  beeing
>     silently  unavailable to the user - until we want to ship it.

Got it.  You want to store the oid of the long table for the base table
inside the pg_class/Relation structure.  Good idea.

> 
>     I think these are the best places to  put  the  configuration
>     into,  because  the information would be already available at
>     no cost inside  heap  access  (rel->rd_rel->rellongrelid  and
>     rel->rd_att...).
> 

Yes, I recommand a macro so access is clear.  See
RelationGetRelationName for an example.

>     What  I  want  to  implement  for  now,  is to store extended
>     VARLENA  attributes  into  a  regular  (but  other   relkind)
>     relation  with  the  Oid  key  as discussed.  That will cause
>     minimum changes to VACUUM. If storage/retrieval of attributes
>     is  encapsulated  right,  it  could get replaced by something
>     different at any time in  the  future  when  we  have  enough
>     experience with this new technique.

Good.  I recommend calling it pg_* so it is automatically excluded from
client table lists.

> 
>     Christof Petig and me then could start implementing it, using
>     lztext with locally  disabled  compression  feature  for  the

I would recommand having compression disabled by default, and enabled by
the user.

>     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, so we are going to see this after 7.0 is released, which is fine.  I
understand the concern about all the accesses to VARDATA() inside the
code.  That will clearly be difficult.

> 
>     This plan means in summary:
> 
>     1.  Full  possible  configurability  with   minimum   catalog
>         changes.
> 
>     2.  Hidden  without any side effects until we agree to enable
>         it.
> 
>     3.  Later optimizable storage of extended attributes.
> 
>     I can't see any reason to way much longer. Can we please have
>     a consensus to get started?

Sounds good.

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

Fri, 17 Dec 1999 12:36:55 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] LONG varsize - how to go on
Bruce Momjian wrote:

> >     What  I  want  to  implement  for  now,  is to store extended
> >     VARLENA  attributes  into  a  regular  (but  other   relkind)
> >     relation  with  the  Oid  key  as discussed.  That will cause
> >     minimum changes to VACUUM. If storage/retrieval of attributes
> >     is  encapsulated  right,  it  could get replaced by something
> >     different at any time in  the  future  when  we  have  enough
> >     experience with this new technique.
>
> Good.  I recommend calling it pg_* so it is automatically excluded from
> client table lists.

    Additionally,  exclude them from psql's \dS by looking at the
    relkind. And for security reasons, disable regular SELECT for
    non-superusers.  Also,  psql's \d should list the "secondary"
    relation name after indices. But that's all stuff far away.

> >
> >     Christof Petig and me then could start implementing it, using
> >     lztext with locally  disabled  compression  feature  for  the
>
> I would recommand having compression disabled by default, and enabled by
> the user.

    Missed me here. I wanted to abuse lztext during  development,
    having that only beeing considered for move off at all to get
    the in place tuple modification going. Then add all the other
    varsize  types  (there  are 12 plus arrays currently) to have
    only one source of errors.

> OK, so we are going to see this after 7.0 is released, which is fine.  I
> understand the concern about all the accesses to VARDATA() inside the
> code.  That will clearly be difficult.

    Seems so.


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



Fri, 17 Dec 1999 18:57:40 +0100 (MET)
wieck@debis.com (Jan Wieck)
Re: [HACKERS] LONG varsize - how to go on
> > >
> > >     Christof Petig and me then could start implementing it, using
> > >     lztext with locally  disabled  compression  feature  for  the
> >
> > I would recommand having compression disabled by default, and enabled by
> > the user.
> 
>     Missed me here. I wanted to abuse lztext during  development,
>     having that only beeing considered for move off at all to get
>     the in place tuple modification going. Then add all the other
>     varsize  types  (there  are 12 plus arrays currently) to have
>     only one source of errors.

Oh, got it.  You are going to implement long tuples for only the lztext
type at first.  Excellent idea.  Did you see someone on the general list
already is asking about long tuples for 7.0?  I replied on our current
status.


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

Fri, 17 Dec 1999 13:12:34 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] LONG varsize - how to go on
Bruce Momjian wrote:

> Oh, got it.  You are going to implement long tuples for only the lztext
> type at first.  Excellent idea.  Did you see someone on the general list
> already is asking about long tuples for 7.0?  I replied on our current
> status.

    I've  seen  several such questions these days. And I fear, if
    I'm not able to get at least  the  required  catalog  changes
    into  7.0,  I'd  have  to  wait  until after 7.0 freeze + CVS
    branch before I can start at all.  That'd cost  us  too  much
    time.

    I  know  that  I  can  deal with a bunch of deferred patches,
    staying in sync with CURRENT and having new features only  as
    patches.  But  that  worx only as long as I have most catalog
    changes in CURRENT. One single concurrent catalog change  can
    cost me days of work in the worst case otherwise.


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



Fri, 17 Dec 1999 20:26:36 +0100 (MET)
wieck@debis.com (Jan Wieck)
Re: [HACKERS] LONG varsize - how to go on
> Bruce Momjian wrote:
> 
> > Oh, got it.  You are going to implement long tuples for only the lztext
> > type at first.  Excellent idea.  Did you see someone on the general list
> > already is asking about long tuples for 7.0?  I replied on our current
> > status.
> 
>     I've  seen  several such questions these days. And I fear, if
>     I'm not able to get at least  the  required  catalog  changes
>     into  7.0,  I'd  have  to  wait  until after 7.0 freeze + CVS
>     branch before I can start at all.  That'd cost  us  too  much
>     time.
> 
>     I  know  that  I  can  deal with a bunch of deferred patches,
>     staying in sync with CURRENT and having new features only  as
>     patches.  But  that  worx only as long as I have most catalog
>     changes in CURRENT. One single concurrent catalog change  can
>     cost me days of work in the worst case otherwise.

The Feb 1 date is not set in stone.  If you would prefer March 1, we can
look at that option.

I pushed for an earlier release because I didn't want to wait for _all_
open items to be completed before a release.

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

Fri, 17 Dec 1999 15:37:55 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] LONG varsize - how to go on
Bruce Momjian wrote:

> >     I  know  that  I  can  deal with a bunch of deferred patches,
> >     staying in sync with CURRENT and having new features only  as
> >     patches.  But  that  worx only as long as I have most catalog
> >     changes in CURRENT. One single concurrent catalog change  can
> >     cost me days of work in the worst case otherwise.
>
> The Feb 1 date is not set in stone.  If you would prefer March 1, we can
> look at that option.

    Let's see how far I can get it in the next 3-4 weeks. Then it
    should have turned out if it's worth to delay the release for
    another couple of weeks or not.

    Had  an  Idea  just  as  I  wrote the (now deleted) text that
    appeared here :-)

    The problem I wanted to write about are  sections  (possible,
    even  if  I don't know about one I haven't written myself :-)
    in the code,  where  a  Datum  is  explicitly  or  implicitly
    casted, to get access to vl_len and vl_dat.

    Well,  I intend to redefine the varlena struct and rename any
    macro that deals with it. This way I'll catch any location in
    the code, that does anything with variable size attributes in
    a usual way.

    We wanted to use the top 2 bits of vl_len for flags,  leaving
    us  a theoretical maximum size of 1GB for one single extended
    attribute value.  Since I want to leave out  the  compression
    part  for  now, I could set the compression info bit ALLWAYS.
    That would force any  part  of  the  code,  where  the  above
    casting  (abuse)  occurs,  to  immediately CRASH at first hit
    (would allocate or access >=1G of memory and I think this  is
    enough to trigger a crash somewhere).  If such a setup passes
    BETA, I'll feel comfortable with it.


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



Fri, 17 Dec 1999 22:14:05 +0100 (MET)
wieck@debis.com (Jan Wieck)
Re: [HACKERS] LONG varsize - how to go on
> Bruce Momjian wrote:
> 
> > >     I  know  that  I  can  deal with a bunch of deferred patches,
> > >     staying in sync with CURRENT and having new features only  as
> > >     patches.  But  that  worx only as long as I have most catalog
> > >     changes in CURRENT. One single concurrent catalog change  can
> > >     cost me days of work in the worst case otherwise.
> >
> > The Feb 1 date is not set in stone.  If you would prefer March 1, we can
> > look at that option.
> 
>     Let's see how far I can get it in the next 3-4 weeks. Then it
>     should have turned out if it's worth to delay the release for
>     another couple of weeks or not.

Yes, let's see how it goes.

> 
>     Had  an  Idea  just  as  I  wrote the (now deleted) text that
>     appeared here :-)
> 
>     The problem I wanted to write about are  sections  (possible,
>     even  if  I don't know about one I haven't written myself :-)
>     in the code,  where  a  Datum  is  explicitly  or  implicitly
>     casted, to get access to vl_len and vl_dat.

You will find only a few files that access vl_len/vl_dat, and the rest
all use macros.  mkid or whatever indexing you use on the source tree
will do nicely.  The bigger question is going to be handling the VARDATA
entries properly when the relate to system tables.  The scope of how
long that data has to exist may be an issue, and textout() may be the
trick in all those cases.  The only issue there is pfree'ing the string
once your are done with it.


> 
>     Well,  I intend to redefine the varlena struct and rename any
>     macro that deals with it. This way I'll catch any location in
>     the code, that does anything with variable size attributes in
>     a usual way.

Yes, but again, just using mkid or something else will find all of them
quickly.

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.

> 
>     We wanted to use the top 2 bits of vl_len for flags,  leaving
>     us  a theoretical maximum size of 1GB for one single extended
>     attribute value.  Since I want to leave out  the  compression
>     part  for  now, I could set the compression info bit ALLWAYS.
>     That would force any  part  of  the  code,  where  the  above
>     casting  (abuse)  occurs,  to  immediately CRASH at first hit
>     (would allocate or access >=1G of memory and I think this  is
>     enough to trigger a crash somewhere).  If such a setup passes
>     BETA, I'll feel comfortable with it.

Yes, makes sense.  Good thing user applications will never see our long
pointers.  That would be very confusing for them.

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.

I don't want a release to cause you any additional work.  Marc is very
clear on that.

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

Fri, 17 Dec 1999 17:02:32 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] LONG varsize - how to go on
> 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) #



Sat, 18 Dec 1999 00:24:13 +0100 (MET)
wieck@debis.com (Jan Wieck)
Re: [HACKERS] LONG varsize - how to go on
wieck@debis.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

Sat, 18 Dec 1999 00:58:53 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] LONG varsize - how to go on 
> 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@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Sat, 18 Dec 1999 01:13:31 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] LONG varsize - how to go on
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@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden



Sat, 18 Dec 1999 17:13:17 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
Re: [HACKERS] LONG varsize - how to go on 
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@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden



Sat, 18 Dec 1999 17:13:28 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
pgindent (Re: [HACKERS] LONG varsize - how to go on)
[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@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Sat, 18 Dec 1999 15:32:35 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: pgindent (Re: [HACKERS] LONG varsize - how to go on)t

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@michvhf.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
==========================================================================



Sat, 18 Dec 1999 16:44:39 -0500 (EST)
Vince Vielhaber <vev@michvhf.com>
Re: pgindent (Re: [HACKERS] LONG varsize - how to go on)t
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Again, I think everyone liked it at the time, but this may have changed.
>
> Speak up, folks.

I can live with the code layout conventions we have in place; I like K&R
layout better, but not enough to fight about it.  It's easy enough to
set up Emacs to handle the style we have.

What I do *not* like is the tab-stops-are-4-spaces convention.  As Peter
says, that makes the code look horrible in any tool that can't easily be
adjusted to a nonstandard tab spacing.

My preference would be to use standard 8-space meaning of tabs, but
stick with our current conventions for visible layout of code (4 columns
per logical indent level, etc).  That means people contributing code
would need to use editors that understand the difference between a
physical tab character and a logical indent level.  I get the impression
that a number of key developers don't use such editors, so maybe
switching over isn't going to be practical.

			regards, tom lane

Sat, 18 Dec 1999 17:14:07 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: pgindent (Re: [HACKERS] LONG varsize - how to go on)
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@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden



Mon, 20 Dec 1999 01:18:46 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
Re: pgindent (Re: [HACKERS] LONG varsize - how to go on)t
[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@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Sun, 19 Dec 1999 21:29:35 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: pgindent (Re: [HACKERS] LONG varsize - how to go on)t
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@debis.com (Jan Wieck) #



Mon, 20 Dec 1999 09:33:32 +0100 (MET)
wieck@debis.com (Jan Wieck)
Re: [HACKERS] LONG varsize - how to go on
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@debis.com (Jan Wieck) #



Mon, 20 Dec 1999 12:15:08 +0100 (MET)
wieck@debis.com (Jan Wieck)
Re: [HACKERS] LONG varsize - how to go on
> 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@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Mon, 20 Dec 1999 09:39:15 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] LONG varsize - how to go on
wieck@debis.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

Mon, 20 Dec 1999 10:02:27 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] LONG varsize - how to go on 
wieck@debis.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

Mon, 20 Dec 1999 10:09:21 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] LONG varsize - how to go on 
> wieck@debis.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@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Mon, 20 Dec 1999 13:04:54 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] LONG varsize - how to go on
> wieck@debis.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@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Mon, 20 Dec 1999 13:09:46 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] LONG varsize - how to go on
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) #



Tue, 21 Dec 1999 00:17:28 +0100 (MET)
wieck@debis.com (Jan Wieck)
Tuple toaster (was: Re: LONG varsize - how to go on)
> 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@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Mon, 20 Dec 1999 21:12:27 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] Tuple toaster (was: Re: LONG varsize - how to go on)