Обсуждение: Open 6.4 items

Additions
------------------
test new cidr/IP address type(Tom Helbekkmo)
complete rewrite system changes(Jan)
notify fixes(Tom)

Serious Items
------------
change pg args for platforms that don't support argv changes
    (setproctitle()?, sendmail hack?)
have psql dump out rules text with new function
man pages/sgml synchronization
generate html/postscript documentation
generate postmaster pid file and remove flock/fcntl lock code
CREATE TABLE test (x text, s serial) fails if no database creation permission
regression test all platforms
make sure all changes are documented properly

Minor items
-----------
cnf-ify still can exhaust memory, make SET KSQO more generic
permissions on indexes:  what do they do?  should it be prevented?
multi-verion concurrency control - work-in-progress for 6.5
improve reporting of syntax errors by showing location of error in query
use index with constants on functions
allow chaining of pages to allow >8k tuples
allow multiple generic operators in expressions without the use of parentheses
document/trigger/rule so changes to pg_shadow create pg_pwd
large objects orphanage
improve group handling
no min/max for oid type
improve PRIMARY KEY handling

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

I'm working on the multi-byte support for win32 env. with help from
Hiroshi Inoue who appears in the discussion on some win32 issues.
In one or two days, I will post new patches that should make
the multi-byte support usable on win32.
Note that only Japanese(Shift-JIS) will be supported in the first
version.

I hope this is not too late for the 6.4 release.
--
Tatsuo Ishii
t-ishii@sra.co.jp

On Sat, 3 Oct 1998, Bruce Momjian wrote:

> Additions

    Rename as 'release stopper'...

> ------------------
> test new cidr/IP address type(Tom Helbekkmo)
> complete rewrite system changes(Jan)
> notify fixes(Tom)

    These have obviously become show stoppers, since they are now half
implemented, and have to be completed before release.  Do we have ETAs on
this stuff?   As things stand right now, we are looking at November 1st
for a release date on v6.4...a month late, but not much worse then other
releases :)  Unfortunately, because of the lateness for some of this, we
haven't done a solid freeze yet, which means that the testing cycle is
going to be a little bit shorter then we like :(

    At this time, I'd like to say that the source tree is now
*absolutely* frozen...no more "just one more thing"...the above three
issues will still need work, as they haven't been fully tested, nor do I
believe them to be fully implemented...but, as a result, they can still be
considered to be "bugs", and, as such, code changes can still be
made/submitted to fix those bugs...

> Serious Items
> ------------
> change pg args for platforms that don't support argv changes
>     (setproctitle()?, sendmail hack?)
> have psql dump out rules text with new function
> man pages/sgml synchronization
> generate html/postscript documentation
> generate postmaster pid file and remove flock/fcntl lock code

    None of these, IMHO, are release stoppers...documentation related
issues don't truly apply to the beta freeze anyway, but unless there is a
real reason that the above coding issues interfere with the ability for
the backend to run on a particular platform, then let's leave them as they
are.  I'm going to look at the setproctitle stuff this week, but will not
be committing any changes until *after* the release, at which time I will
create a seperate patch...

    As for the flock/fcntl lock code...my understanding of it is that
it is only 'startup' related, and doesn't really affect anything...leave
it there for now, create a patch shortly after release that can be used to
remove it if it is causing problems for some...

> CREATE TABLE test (x text, s serial) fails if no database creation permission

    release stopper...please move it up with the other three...

> regression test all platforms

    same as the CREATE TABLE...

> make sure all changes are documented properly

    not included as part of beta freeze, changes here can be made at
any time up till the release date, since it does not affect the running of
the backend...

> Minor items
> -----------
> cnf-ify still can exhaust memory, make SET KSQO more generic
> permissions on indexes:  what do they do?  should it be prevented?
> multi-verion concurrency control - work-in-progress for 6.5
> improve reporting of syntax errors by showing location of error in query
> use index with constants on functions
> allow chaining of pages to allow >8k tuples
> allow multiple generic operators in expressions without the use of parentheses
> document/trigger/rule so changes to pg_shadow create pg_pwd
> large objects orphanage
> improve group handling
> no min/max for oid type
> improve PRIMARY KEY handling

    actually, I'd pretty much say that none of the 'minor' ones are
release stoppers...and, as such, should be moved over to "todo for
v6.5"...

    For v6.4, can we just concentrate on, and remove from the list
everything else, the following:

> test new cidr/IP address type(Tom Helbekkmo)
> complete rewrite system changes(Jan)
> notify fixes(Tom)
> CREATE TABLE test (x text, s serial) fails if no database creation permission
> regression test all platforms

    Everything else appears to be a "ya, be nice if we could, but it can
wait" sort of issue...

    If we can get those 5 cleaned up/out, then I think we have a good
release candidate to snapshot and test...

Marc G. Fournier                               scrappy@hub.org
Systems Administrator @ hub.org
scrappy@{postgresql|isc}.org                       ICQ#7615664

"Marc G. Fournier" <scrappy@hub.org> writes:
>     Rename as 'release stopper'...
>> notify fixes(Tom)
>> [other items snipped]
>     These have obviously become show stoppers, since they are now half
> implemented, and have to be completed before release.  Do we have ETAs on
> this stuff?

My notify rewrite is not in the tree at all right now.  I thought we had
agreed (off-list) not to put that change into 6.4, but to postpone it
to the next release.

> As things stand right now, we are looking at November 1st
> for a release date on v6.4...a month late, but not much worse then other
> releases :)

On the other hand, if release is going to be 11/1 not 10/1, my personal
vote is to put the notify changes in.  If there are any bugs, that ought
to be time enough to shake them out.

I can commit those changes tonight if I have the go-ahead.  Or I can
wait till post-6.4.  Your call.

>> Serious Items
>> ------------
>> [snippage]
>> generate postmaster pid file and remove flock/fcntl lock code

>     None of these, IMHO, are release stoppers...

flock is a release stopper as far as I'm concerned, because the backend
*does not compile* on my platform without diking out that code.  I agree
that it is too late to try to rewrite the feature correctly for 6.4.
What say we put in an autoconf test for whether flock exists, and make
the new code conditional on that?  People without flock would see the
same old behavior, which is good enough for now.  I will volunteer to
make the necessary changes if that strategy is agreed on.

            regards, tom lane

On Mon, 5 Oct 1998, Tom Lane wrote:

> "Marc G. Fournier" <scrappy@hub.org> writes:
> >     Rename as 'release stopper'...
> >> notify fixes(Tom)
> >> [other items snipped]
> >     These have obviously become show stoppers, since they are now half
> > implemented, and have to be completed before release.  Do we have ETAs on
> > this stuff?
>
> My notify rewrite is not in the tree at all right now.  I thought we had
> agreed (off-list) not to put that change into 6.4, but to postpone it
> to the next release.

    *slap forehead*

> > As things stand right now, we are looking at November 1st
> > for a release date on v6.4...a month late, but not much worse then other
> > releases :)
>
> On the other hand, if release is going to be 11/1 not 10/1, my personal
> vote is to put the notify changes in.  If there are any bugs, that ought
> to be time enough to shake them out.
>
> I can commit those changes tonight if I have the go-ahead.  Or I can
> wait till post-6.4.  Your call.

    Go for it...that will at least get them off the list...

> flock is a release stopper as far as I'm concerned, because the backend
> *does not compile* on my platform without diking out that code.  I agree
> that it is too late to try to rewrite the feature correctly for 6.4.
> What say we put in an autoconf test for whether flock exists, and make
> the new code conditional on that?  People without flock would see the
> same old behavior, which is good enough for now.  I will volunteer to
> make the necessary changes if that strategy is agreed on.

    Make it so...

>I'm working on the multi-byte support for win32 env. with help from
>Hiroshi Inoue who appears in the discussion on some win32 issues.
>In one or two days, I will post new patches that should make
>the multi-byte support usable on win32.
>Note that only Japanese(Shift-JIS) will be supported in the first
>version.

Here are the patches against the current source tree. I have run the
regression test on a FreeBSD box with both non-MULTIBYTE and
MULTIBYTE-enabled, and confirmed that the results are same.

However I do not tested on PCs(I don't have access to win). Please let
me know if the patches break anything on PCs.

Also please note that the patch for varchar.c is a fix for a nasty bug
of char(n) types that I introduced and I believe at least this should
be applied.

Affected files are:
src/win32.mak
src/bin/psql/win32.mak
src/interfaces/libpq/win32.mak
src/interfaces/libpq/libpqdll.def
src/interfaces/libpq/fe-print.c
src/backend/utils/mb/common.c
src/backend/utils/adt/varchar.c


Index: src/win32.mak
===================================================================
RCS file: /usr/local/cvsroot/pgsql/src/win32.mak,v
retrieving revision 1.2
diff -c -r1.2 win32.mak
*** win32.mak    1998/08/27 13:25:11    1.2
--- win32.mak    1998/10/05 06:33:48
***************
*** 10,19 ****
  NULL=nul
  !ENDIF

  ALL:
     cd interfaces\libpq
!    nmake /f win32.mak
     cd ..\..\bin\psql
!    nmake /f win32.mak
     cd ..\..
     echo All Win32 parts have been built!
--- 10,23 ----
  NULL=nul
  !ENDIF

+ !IFDEF    MULTIBYTE
+ MAKEMACRO = "MULTIBYTE=$(MULTIBYTE)"
+ !ENDIF
+
  ALL:
     cd interfaces\libpq
!    nmake /f win32.mak $(MAKEMACRO)
     cd ..\..\bin\psql
!    nmake /f win32.mak $(MAKEMACRO)
     cd ..\..
     echo All Win32 parts have been built!
Index: src/bin/psql/win32.mak
===================================================================
RCS file: /usr/local/cvsroot/pgsql/src/bin/psql/win32.mak,v
retrieving revision 1.2
diff -c -r1.2 win32.mak
*** win32.mak    1998/09/03 02:16:27    1.2
--- win32.mak    1998/10/05 06:33:48
***************
*** 29,34 ****
--- 29,42 ----
  CPP_PROJ=/nologo /ML /W3 /GX /O2 /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D\
   "_MBCS" /Fp"$(INTDIR)\psql.pch" /YX /Fo"$(INTDIR)\\" /Fd"$(INTDIR)\\" /FD /c \
   /I ..\..\include /I ..\..\interfaces\libpq
+
+ !IFDEF    MULTIBYTE
+ !IFNDEF MBFLAGS
+ MBFLAGS="-DMULTIBYTE=$(MULTIBYTE)"
+ !ENDIF
+ CPP_PROJ=$(MBFLAGS) $(CPP_PROJ)
+ !ENDIF
+
  CPP_OBJS=.\Release/
  CPP_SBRS=.

Index: src/interfaces/libpq/win32.mak
===================================================================
RCS file: /usr/local/cvsroot/pgsql/src/interfaces/libpq/win32.mak,v
retrieving revision 1.3
diff -c -r1.3 win32.mak
*** win32.mak    1998/09/18 16:46:07    1.3
--- win32.mak    1998/10/05 06:33:48
***************
*** 33,39 ****
      -@erase "$(OUTDIR)\libpq.lib"
      -@erase "$(OUTDIR)\libpq.dll"
      -@erase "$(OUTDIR)\libpq.res"
!     -@erase "$(OUTDIR)\vc*.*"
      -@erase "$(OUTDIR)\libpq.pch"
      -@erase "$(OUTDIR)\libpqdll.exp"
      -@erase "$(OUTDIR)\libpqdll.lib"
--- 33,39 ----
      -@erase "$(OUTDIR)\libpq.lib"
      -@erase "$(OUTDIR)\libpq.dll"
      -@erase "$(OUTDIR)\libpq.res"
!     -@erase "vc50.pch"
      -@erase "$(OUTDIR)\libpq.pch"
      -@erase "$(OUTDIR)\libpqdll.exp"
      -@erase "$(OUTDIR)\libpqdll.lib"
***************
*** 44,49 ****
--- 44,57 ----
  CPP_PROJ=/nologo /ML /W3 /GX /O2 /I "..\..\include" /D "NDEBUG" /D\
   "WIN32" /D "_WINDOWS" /Fp"$(INTDIR)\libpq.pch" /YX\
   /Fo"$(INTDIR)\\" /Fd"$(INTDIR)\\" /FD /c
+
+ !IFDEF MULTIBYTE
+ !IFNDEF    MBFLAGS
+ MBFLAGS="-DMULTIBYTE=$(MULTIBYTE)"
+ !ENDIF
+ CPP_PROJ = $(CPP_PROJ) $(MBFLAGS)
+ !ENDIF
+
  CPP_OBJS=.\Release/
  CPP_SBRS=.

***************
*** 57,62 ****
--- 65,74 ----
      "$(INTDIR)\fe-lobj.obj" \
      "$(INTDIR)\fe-misc.obj" \
      "$(INTDIR)\fe-print.obj"
+
+ !IFDEF MULTIBYTE
+ LIB32_OBJS = $(LIB32_OBJS) $(INTDIR)\common.obj $(INTDIR)\wchar.obj $(INTDIR)\conv.obj
+ !ENDIF

  RSC_PROJ=/l 0x409 /fo"$(INTDIR)\libpq.res"

Index: src/interfaces/libpq/libpqdll.def
===================================================================
RCS file: /usr/local/cvsroot/pgsql/src/interfaces/libpq/libpqdll.def,v
retrieving revision 1.4
diff -c -r1.4 libpqdll.def
*** libpqdll.def    1998/10/01 01:40:26    1.4
--- libpqdll.def    1998/10/05 06:33:48
***************
*** 63,66 ****
      lo_unlink        @ 60
      lo_import        @ 61
      lo_export        @ 62
!     PQresultErrorMessage    @ 63
--- 63,67 ----
      lo_unlink        @ 60
      lo_import        @ 61
      lo_export        @ 62
!     pgresStatus        @ 63
!     PQmblen            @ 64
Index: src/interfaces/libpq/fe-print.c
===================================================================
RCS file: /usr/local/cvsroot/pgsql/src/interfaces/libpq/fe-print.c,v
retrieving revision 1.13
diff -c -r1.13 fe-print.c
*** fe-print.c    1998/10/04 20:46:39    1.13
--- fe-print.c    1998/10/05 06:33:49
***************
*** 513,519 ****
      return (pg_encoding_mblen(encoding, s));
  }

! #endif

  static void
  do_field(PQprintOpt *po, PGresult *res,
--- 513,529 ----
      return (pg_encoding_mblen(encoding, s));
  }

! #else
!
! #ifdef WIN32
! int
! PQmblen(unsigned char *s)
! {
! }
! #endif    /* WIN32 */
!
!
! #endif    /* MULTIBYTE */

  static void
  do_field(PQprintOpt *po, PGresult *res,
Index: src/backend/utils/mb/common.c
===================================================================
RCS file: /usr/local/cvsroot/pgsql/src/backend/utils/mb/common.c,v
retrieving revision 1.2
diff -c -r1.2 common.c
*** common.c    1998/09/01 04:33:19    1.2
--- common.c    1998/10/05 06:33:49
***************
*** 4,10 ****
   * Tatsuo Ishii
   * $Id: common.c,v 1.2 1998/09/01 04:33:19 momjian Exp $ */

! #include <stdio.h>
  #include <string.h>

  #include "mb/pg_wchar.h"
--- 4,19 ----
   * Tatsuo Ishii
   * $Id: common.c,v 1.2 1998/09/01 04:33:19 momjian Exp $ */

! #include <stdlib.h>
!
! #ifdef WIN32
! #include "win32.h"
! #else
! #if !defined(NO_UNISTD_H)
! #include <unistd.h>
! #endif
! #endif
!
  #include <string.h>

  #include "mb/pg_wchar.h"
Index: src/backend/utils/adt/varchar.c
===================================================================
RCS file: /usr/local/cvsroot/pgsql/src/backend/utils/adt/varchar.c,v
retrieving revision 1.41
diff -c -r1.41 varchar.c
*** varchar.c    1998/09/25 15:51:02    1.41
--- varchar.c    1998/10/05 06:33:50
***************
*** 163,169 ****
  #ifdef MULTIBYTE
      /* truncate multi-byte string in a way not to break
         multi-byte boundary */
!     slen = pg_mbcliplen(VARDATA(s), rlen, rlen);
  #else
      slen = VARSIZE(s) - VARHDRSZ;
  #endif
--- 163,173 ----
  #ifdef MULTIBYTE
      /* truncate multi-byte string in a way not to break
         multi-byte boundary */
!     if (VARSIZE(s) > len) {
!         slen = pg_mbcliplen(VARDATA(s), VARSIZE(s)-VARHDRSZ, rlen);
!         } else {
!         slen = VARSIZE(s) - VARHDRSZ;
!         }
  #else
      slen = VARSIZE(s) - VARHDRSZ;
  #endif

"Marc G. Fournier" <scrappy@hub.org> writes:
>> I can commit those changes tonight if I have the go-ahead.  Or I can
>> wait till post-6.4.  Your call.

>     Go for it...that will at least get them off the list...

OK, the NOTIFY rewrite is checked in.  We'll see what breaks, if
anything.

>> flock is a release stopper as far as I'm concerned, because the backend
>> *does not compile* on my platform without diking out that code.

Actually, it looks like Vadim replaced the flock() call with fcntl() a
few weeks ago, and I'd not noticed because I had a locally modified copy
of pqcomm.c.  I don't know if fcntl(F_SETLK) is any more portable than
flock() --- it compiles on my platform, where flock() didn't, but that
proves little.  So I went ahead and put in an autoconf test, only
checking for fcntl(F_SETLK) rather than flock().  I still think the
process-pid-in-a-textfile approach to locking is safer, but we can
leave that for the next release.

That's two items off the must-fix list and onto the are-there-bugs?
list...

            regards, tom lane

Applied.

> >I'm working on the multi-byte support for win32 env. with help from
> >Hiroshi Inoue who appears in the discussion on some win32 issues.
> >In one or two days, I will post new patches that should make
> >the multi-byte support usable on win32.
> >Note that only Japanese(Shift-JIS) will be supported in the first
> >version.
>
> Here are the patches against the current source tree. I have run the
> regression test on a FreeBSD box with both non-MULTIBYTE and
> MULTIBYTE-enabled, and confirmed that the results are same.
>
> However I do not tested on PCs(I don't have access to win). Please let
> me know if the patches break anything on PCs.
>
> Also please note that the patch for varchar.c is a fix for a nasty bug
> of char(n) types that I introduced and I believe at least this should
> be applied.
>
> Affected files are:
> src/win32.mak
> src/bin/psql/win32.mak
> src/interfaces/libpq/win32.mak
> src/interfaces/libpq/libpqdll.def
> src/interfaces/libpq/fe-print.c
> src/backend/utils/mb/common.c
> src/backend/utils/adt/varchar.c


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