Re: [HACKERS] Open 6.4 items

From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
To: lockhart(at)alumni(dot)caltech(dot)edu (Thomas G(dot) Lockhart)
Cc: hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Open 6.4 items
Date: 1998-08-25 02:58:56
Message-ID: 199808250258.WAA02834@candle.pha.pa.us
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.

Yep. Remember Marc's rule that you can't add features after beta
starts, but you can be fixing things. That buys us a lot of time.

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

Not required. Again, there are NEW items. If they don't get fixed,
they are moved to the TODO list.

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

Probably too large for 6.4 at this point.

>
> > allow chainging of pages to allow >8k tuples
>
> One week before beta freeze. Won't be in v6.4, right?

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.

This would be nice to have for 6.4. Someone mentioned you can create
the sequence before the table, so maybe we can jam it in. If it is not
100% correct, we have a month to make it correct, right?

>
> > fix problem when DEFAULT string for CHAR() is not same as column
>
> Who is pursuing this? Where does the problem come from?

I am attaching the posting describing the problem. If anyone wants to
see the actual problem reports for any item, let me know. I can send
you my entire mailbox of 70 items if you wish.

>
> > remove PARSEDEBUG defines if not longer needed
>
> Yeah, yeah :)

Remember, I suggested a way you could keep them with more eligant
defines. Any comments?

>
> > double-quotes from pg_dump of field names
>
> I have some patches for this, but have not had time to test yet.

Cool. Let the beta testers test it!

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

Great.

--
Bruce Momjian | 830 Blythe Avenue
maillist(at)candle(dot)pha(dot)pa(dot)us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)

Attachment Content-Type Size
unknown_filename text/plain 0 bytes

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 1998-08-25 03:15:38 rewrite system and Resdom
Previous Message Thomas G. Lockhart 1998-08-25 02:57:17 Re: [GENERAL] More details on Database corruption