Open 6.4 items

Thanks. Applied.

Bruce Momjian wrote:

Additions
---------
CREATE TABLE test (x text, s serial) fails if no database creation permission
regression test all platforms

The patch below arranges that the sequence(s) get created
first. Unprivileged user now can create table with serial
columns.

Regression tested.

So Marc's assumption that his BETA3 is what we release was
false. We really know how to trigger his hot buttons - eh?
:-)

You want even worse. I fixed a problem in the system table just now
with the lseg_eq <> problem. That requires an initdb for people to see
the fix.

But we might as well fix it now, because we can't ask for initdb after
the final release.

Can someone check that that fix does not affect the regression test
results? I doubt we do lseg not-equal tests in the regression suite.
You will have to do an initdb to see the change.

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

Here are the open items. Thanks to Jan, the only 'hot' item left is the
ps args issue. People on non-BSD platforms will see all their backends
called 'postmaster', because argv[0] changes do not reflect in ps arg
displays.

I have asked that at least we get set_proctitle() working for Linux, but
no one wants to do it, and we can't remove the it because we would have
to add the exec() back into backend creation, which is impossible at
this point.

I'm running Linux 2.1.88 and get

15572 p2 S 0:01 /usr/local/pgsql/bin/postmaster -o -F
16121 p2 S 0:01 /usr/local/pgsql/bin/postgres localhost twieck twieck idle

from ps. So what isn't working?

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #

Here are the open items. Thanks to Jan, the only 'hot' item left is the
ps args issue. People on non-BSD platforms will see all their backends
called 'postmaster', because argv[0] changes do not reflect in ps arg
displays.

Bruce,

I asked for it a while ago but forgot about it. Anyway - I
think it is better to have precreated gram.c, y.tab.h and
scan.c files in src/pl/plpgsql/src too. Otherwise ppl not
having bison/flex might have a build problem.

The only thing required is to take them out of the 'clean' rm
in Makefile.in and add the bison/flex created files to CVS.
If gram.c, y.tab.h and scan.l are present and newer than
gram.y and scan.l the Makefile will already skip the steps to
create them.

Do they fail for people who have standard BSD yacc? Too large? No one
has complained about it, but it may be true.

Done. Removed from Makefile.in, and added via cvs.

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

Here are the open items. Thanks to Jan, the only 'hot' item left is the
ps args issue. People on non-BSD platforms will see all their backends
called 'postmaster', because argv[0] changes do not reflect in ps arg
displays.

Bruce,

I asked for it a while ago but forgot about it. Anyway - I
think it is better to have precreated gram.c, y.tab.h and
scan.c files in src/pl/plpgsql/src too. Otherwise ppl not
having bison/flex might have a build problem.

The only thing required is to take them out of the 'clean' rm
in Makefile.in and add the bison/flex created files to CVS.
If gram.c, y.tab.h and scan.l are present and newer than
gram.y and scan.l the Makefile will already skip the steps to
create them.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #

The only thing required is to take them out of the 'clean' rm
in Makefile.in and add the bison/flex created files to CVS.
If gram.c, y.tab.h and scan.l are present and newer than
gram.y and scan.l the Makefile will already skip the steps to
create them.

We should do that for the ecpg pre-processor also.

- Tom

Bruce Momjian <maillist@candle.pha.pa.us> writes:

Here are the open items. Thanks to Jan, the only 'hot' item left is the
ps args issue. People on non-BSD platforms will see all their backends
called 'postmaster', because argv[0] changes do not reflect in ps arg
displays.

I have asked that at least we get set_proctitle() working for Linux, but
no one wants to do it, and we can't remove the it because we would have
to add the exec() back into backend creation, which is impossible at
this point.

I think I was one of the louder complainers about the lack of proctitle
information, but even I don't think it's worth holding up the release
for --- and it's certainly not worth taking a strong risk of breakage
at this stage. Let's put it on the to-do-for-6.4.1 list.

regards, tom lane

jwieck@debis.com (Jan Wieck) writes:

I asked for it a while ago but forgot about it. Anyway - I
think it is better to have precreated gram.c, y.tab.h and
scan.c files in src/pl/plpgsql/src too. Otherwise ppl not
having bison/flex might have a build problem.

There are quite a few places that need lex/yacc capability; plpgsql
is not creating any new build requirement that did not exist before.
(ecpg and bootparse are two examples I can think of offhand.)
We ship the main gram.c file not to avoid requiring lex/yacc, but
because it is too big for some older yaccs.

It might be nice to eliminate the need for lex/yacc capability,
but post-beta3 is NOT the time to be doing "might be nice" stuff.
Leave it be for now.

regards, tom lane

PS: BTW, I was able to build all the Postgres yacc files on a rather
ancient HPUX yacc, once I added enough -N switches. According to my
notes,
YACC:/usr/bin/yacc
YFLAGS:-d -Np2000 -Ns3000 -Nm100000 -Nl2000 -Na30000 -Nc10000
worked with a pretty recent fileset. So I'm not sure we even really
need to distribute the main parser's gram.c. We could have configure
plug in these switches if it fails to find bison...

Bruce,

I asked for it a while ago but forgot about it. Anyway - I
think it is better to have precreated gram.c, y.tab.h and
scan.c files in src/pl/plpgsql/src too. Otherwise ppl not
having bison/flex might have a build problem.

The only thing required is to take them out of the 'clean' rm
in Makefile.in and add the bison/flex created files to CVS.
If gram.c, y.tab.h and scan.l are present and newer than
gram.y and scan.l the Makefile will already skip the steps to
create them.

Do they fail for people who have standard BSD yacc? Too large? No one
has complained about it, but it may be true.

They shouldn't be too large. But they get modified with
sed(1) since this is a second independend scanner/parser
inside the backend (after loading). I'm not 100% sure if the
code generated by ANY other lex/yacc accepts the
substitutions or if the resulting code is really that
independet as it should be.

Done. Removed from Makefile.in, and added via cvs.

Thanks.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #

Bruce Momjian <maillist@candle.pha.pa.us> writes:

But we might as well fix it now, because we can't ask for initdb after
the final release.

Can someone check that that fix does not affect the regression test
results? I doubt we do lseg not-equal tests in the regression suite.
You will have to do an initdb to see the change.

I just rebuilt and initdb'd. Regression test state is the same
as before, except that the new inet test fails:

*** expected/inet.out	Tue Oct 27 14:34:02 1998
--- results/inet.out	Wed Oct 28 14:02:45 1998
***************
*** 53,66 ****
    i as inet, network(i) as "network(inet)" FROM INET_TBL;
  eight|cidr        |network(cidr)|inet            |network(inet)
  -----+------------+-------------+----------------+-------------
!      |192.168.1/24|  0.1.168.192|192.168.1.226/24|  0.1.168.192
!      |192.168.1/24|  0.1.168.192|192.168.1.226   |226.1.168.192
!      |10/8        |     0.0.0.10|10.1.2.3/8      |     0.0.0.10
!      |10.0.0.0/32 |     0.0.0.10|10.1.2.3/8      |     0.0.0.10
!      |10.1.2.3/32 |     3.2.1.10|10.1.2.3        |     3.2.1.10
!      |10.1.2/24   |     0.2.1.10|10.1.2.3/24     |     0.2.1.10
!      |10.1/16     |     0.0.1.10|10.1.2.3/16     |     0.0.1.10
!      |10/8        |     0.0.0.10|10.1.2.3/8      |     0.0.0.10
  (8 rows)

  QUERY: SELECT '' as eight, c as cidr, masklen(c) as "masklen(cidr)",
--- 53,66 ----
    i as inet, network(i) as "network(inet)" FROM INET_TBL;
  eight|cidr        |network(cidr)|inet            |network(inet)
  -----+------------+-------------+----------------+-------------
!      |192.168.1/24|  192.168.1.0|192.168.1.226/24|  192.168.1.0
!      |192.168.1/24|  192.168.1.0|192.168.1.226   |192.168.1.226
!      |10/8        |     10.0.0.0|10.1.2.3/8      |     10.0.0.0
!      |10.0.0.0/32 |     10.0.0.0|10.1.2.3/8      |     10.0.0.0
!      |10.1.2.3/32 |     10.1.2.3|10.1.2.3        |     10.1.2.3
!      |10.1.2/24   |     10.1.2.0|10.1.2.3/24     |     10.1.2.0
!      |10.1/16     |     10.1.0.0|10.1.2.3/16     |     10.1.0.0
!      |10/8        |     10.0.0.0|10.1.2.3/8      |     10.0.0.0
  (8 rows)

QUERY: SELECT '' as eight, c as cidr, masklen(c) as "masklen(cidr)",

----------------------

Offhand I would say that it's the "expected" file that is broken.
Shouldn't those octets be coming out in the other order?

regards, tom lane

On Wed, 28 Oct 1998, Bruce Momjian wrote:

Here are the open items. Thanks to Jan, the only 'hot' item left is the
ps args issue. People on non-BSD platforms will see all their backends
called 'postmaster', because argv[0] changes do not reflect in ps arg
displays.

Since there were no problem reports for this, I assumed that it
was an 'asthetic change' more then anything. Once v6.4 is released, I'll
dive into it with the Linux guys here at the University...

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

jwieck@debis.com (Jan Wieck) writes:

I asked for it a while ago but forgot about it. Anyway - I
think it is better to have precreated gram.c, y.tab.h and
scan.c files in src/pl/plpgsql/src too. Otherwise ppl not
having bison/flex might have a build problem.

There are quite a few places that need lex/yacc capability; plpgsql
is not creating any new build requirement that did not exist before.
(ecpg and bootparse are two examples I can think of offhand.)
We ship the main gram.c file not to avoid requiring lex/yacc, but
because it is too big for some older yaccs.

It might be nice to eliminate the need for lex/yacc capability,
but post-beta3 is NOT the time to be doing "might be nice" stuff.
Leave it be for now.

regards, tom lane

PS: BTW, I was able to build all the Postgres yacc files on a rather
ancient HPUX yacc, once I added enough -N switches. According to my
notes,
YACC:/usr/bin/yacc
YFLAGS:-d -Np2000 -Ns3000 -Nm100000 -Nl2000 -Na30000 -Nc10000
worked with a pretty recent fileset. So I'm not sure we even really
need to distribute the main parser's gram.c. We could have configure
plug in these switches if it fails to find bison...

Again, too late to play with. BSD yacc doesn't have switches that
enable larger tables, so you have to have gram.c. Does plpgsql have
tables too large for BSD yacc? Can someone test it?

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

On Wed, 28 Oct 1998, Bruce Momjian wrote:

Here are the open items. Thanks to Jan, the only 'hot' item left is the
ps args issue. People on non-BSD platforms will see all their backends
called 'postmaster', because argv[0] changes do not reflect in ps arg
displays.

Since there were no problem reports for this, I assumed that it
was an 'asthetic change' more then anything. Once v6.4 is released, I'll
dive into it with the Linux guys here at the University...

Looks like it works for most people. I will remove it from the list,
and see if someone complains.

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