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