Re: Open 7.3 items

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Open 7.3 items
Дата
Msg-id 24854.1028091018@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Open 7.3 items  (Bruce Momjian <pgman@candle.pha.pa.us>)
Ответы Re: Open 7.3 items  (Tatsuo Ishii <t-ishii@sra.co.jp>)
Trim the Fat (Was: Re: Open 7.3 items )  ("Marc G. Fournier" <scrappy@hub.org>)
Re: Open 7.3 items  ("Christopher Kings-Lynne" <chriskl@familyhealth.com.au>)
Re: Open 7.3 items  ("Kaare Rasmussen" <kar@kakidata.dk>)
Re: Open 7.3 items  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: Open 7.3 items  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: Open 7.3 items  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: Open 7.3 items  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers
Bruce Momjian <pgman@candle.pha.pa.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Yuva Chandolu
Дата:
Сообщение: Re: Outer join differences
Следующее
От: "Dann Corbit"
Дата:
Сообщение: Re: Open 7.3 items