Re: [HACKERS] Open 6.4 items

From: "Thomas G(dot) Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu>
To: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
Cc: PostgreSQL-development <hackers(at)postgreSQL(dot)org>
Subject: Re: [HACKERS] Open 6.4 items
Date: 1998-08-24 15:27:59
Message-ID: 35E1867F.96B11C7B@alumni.caltech.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> man pages/sgml synchronization (dump out man pages as postscript?)

I'll need the sgml docs to firm up two weeks before release (Sept 15?)
to give time to generate hardcopy. The admin guide will be the last
converted, and it has the release notes and installation procedure which
need to be updated. Can we think about how to do the release notes and
installation for this release? I would suggest having a short readme on
how to install and read the docs, and have the detailed installation
procedure in sgml->html/hardcopy.

> improve reporting syntax errors by showing location of error in query

We haven't had this in previous releases. Not required for v6.4, right?

> use index with constants on functions

We haven't had this in previous releases. I know how to do it, I think,
but am not seeing when I could get to it. How important is it??

> allow chainging of pages to allow >8k tuples

One week before beta freeze. Won't be in v6.4, right?

> SERIAL type auto-creates sequence

I won't have time to do this for v6.4. It's not quite the same as the
PRIMARY KEY parser solution, since the sequence must be created _before_
the main portion of the CREATE TABLE command is executed, rather than
after. We should go through the high-level parser routines and allow all
of them to return multiple parse trees; at the moment I've got a
special-case workaround implemented for the PRIMARY KEY code which
doesn't generalize very well.

> fix problem when DEFAULT string for CHAR() is not same as column

Who is pursuing this? Where does the problem come from?

> remove PARSEDEBUG defines if not longer needed

Yeah, yeah :)

> double-quotes from pg_dump of field names

I have some patches for this, but have not had time to test yet.

> Allow IN in DEFAULT section

Already done and in the cvs tree:
postgres=> create table t (i int, check (i in (1, 2, 3)));
CREATE

I fixed NOT LIKE and NOT IN at the same time...

- Tom

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 1998-08-24 15:34:41 Re: [INTERFACES] Re: [HACKERS] Convert PGconn, PGresult to opaque types?
Previous Message Thomas G. Lockhart 1998-08-24 15:01:39 Re: [GENERAL] More details on Database corruption