Re: Open 7.3 items

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Open 7.3 items
Date: 2002-07-31 04:50:18
Message-ID: 24854.1028091018@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Here are the open items for 7.3.

Some comments ...

> Socket permissions - only install user can access db by default

I do not agree with this goal.

> NAMEDATALEN - disk/performance penalty for increase, 64, 128?
> FUNC_MAX_ARGS - disk/performance penalty for increase, 24, 32?

At the moment I don't see a lot of solid evidence that increasing
NAMEDATALEN has any performance penalty. Someone reported about
a 10% slowdown on pgbench with NAMEDATALEN=128 ... but Neil Conway
tried to reproduce the result, and got about a 10% *speedup*.
Personally I think 10% is well within the noise spectrum for
pgbench, and so it's difficult to claim that we have established
any performance difference at all. I have not tried to measure
FUNC_MAX_ARGS differences.

> Point-in-time recovery - ready for 7.3?

At the moment, it doesn't exist at all. If patches appear, we can
review 'em, but right now there is nothing to debate.

> DROP COLUMN - ready?

I'm on it.

> Win32 - timefame?

I've seen nothing to make me think this will be ready for 7.3.

> Prepared statements - ready?

I think we're close there; the patch seems okay, we're just debating
minor syntax issues.

> Schema handling - ready? interfaces? client apps?

The backend will be ready (it's not quite yet). pg_dump is ready.
psql is very definitely not ready, nor is pgaccess. I don't know the
status for JDBC or ODBC; any comments? The other interface libraries
probably don't care.

> Dependency - pg_dump auto-create dependencies for 7.2.X data?

Huh?

> glibc and mktime() - fix?

We need a fix for this. Dunno what to do about it.

> ecpg and bison issues - solved?

Not yet :-(. Anyone have a line into the bison project?

Other things on my radar screen:

* I have about zero confidence in the recent tuple-header-size-reduction
patches.

* pg_conversion stuff --- do we understand this thing's behavior under
failure conditions? Does it work properly with namespaces and
dependencies?

* pg_dumpall probably ought to dump database privilege settings, also
per-user and per-database GUC settings.

* BeOS and QNX4 ports are busted.

* The whole area of which implicit coercions should be allowed is a
serious problem that we have not spent enough time on. There are
a number of cases in which CVS tip is clearly broken compared to
prior releases.

* Bear Giles' SSL patches seem to be causing unhappiness in some
quarters.

* libpqxx is not integrated into build process nor docs. It should
be integrated or reversed out before beta.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dann Corbit 2002-07-31 04:56:28 Re: Open 7.3 items
Previous Message Yuva Chandolu 2002-07-31 04:46:57 Re: Outer join differences