Subject: Querys on ongoing projects...

From: [email-masked]
Date: Sun, 3 Jan 93 18:11:07 -0800

[As I am a newbie on this list, and as these are likely faqs, if you
feel like spewing bile, please do so via mail direct to me so the rest
of the world can live in peace...]

I desire to correspond with people who are involved in any of the
following projects WRT postgres 4.0.1:

1) Ansification of the source.

2) Posixification of the source.

3) Other portability changes to the source, such as:
  a) Removing yaccocentric code to allow use of other (e.g posix or
bison) compiler-compilers.
  b) Removing flexocentric code for similar reasons.
  c) Un-necessary bsdisms or sunisms.

4) Modifying the distribution to use a more comprehensive
multi-platform building technology (say Imake).

5) Porting to SVR4.

Additionally, if you have the answer to any of these questions, I'd
like to hear from you:

6) Is the postgres group likely to fix unportabilities if they are
reported as bugs?

7) Can anyone explain why the rather curious SkipForwardToFromList()
method is used in parser/gram.y, instead of a more straightforward
method?

8) Why the postquel grammer enforces ordering of clauses in
statements, instead of allowing them to be in any order?  They could
just as easily and efficently be parsed, and there seems to be no
compelling stylistic reason for enforcing the ordering.  For example

  ``retrieve (x) into y''

seems to make at least as much stylistic sense to me as (the
required):

  ``retrieve into y (x)''.

Thanks!

---
 Robert Withrow, Tel: +1 617 598 4480, Fax: +1 617 598 4430, Net: [email-masked]
 R.W. Withrow Associates, 21 Railroad Ave, Swampscott MA 01907-1821 USA

---

From: [email-masked]
Date: Sun, 03 Jan 93 20:01:18 -0800

> 1) Ansification of the source.

It is on the aggenda for the coming release.  We are trying to do this
in a way that will allow compilation by non-ANSI compilers, and let us
use the new ANSI features to best advantage.

>   c) Un-necessary bsdisms or sunisms.

These are continuing trends in our code, particularly as we change our
'supported' platforms away from machines like the sequent, and towards
the HP snakes, Alphas, and i386BSD.

> multi-platform building technology (say Imake).

done.  The next release will use the new berkeley make which will be
included in the distribution.

> 6) Is the postgres group likely to fix unportabilities if they are

We'll certainly consider it.  We are already considering some of the
major unportabilities in postgres including assumptions we made about
the size of longs, old K&R-isms, etc.

later,
Adam Glass
postgres research group