Re: HISTORY file

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: HISTORY file
Date: 2001-10-29 19:10:11
Message-ID: 200110291910.f9TJABl11722@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


[ Sorry I am two days late in responding to this.]

> I find the HISTORY file to be distressingly poor to peruse. Reasons:

While I do my best to generate the HISTORY file, it is far from perfect.
I need comments like this to help me improve it. Peter, glad you took
the time to review the list. Let me address each one and modify the
HISTORY file accordingly:

>
> A large proportion of the items don't convey any useful information.
> Examples:
>
> | PLpgSQL fix for SELECT... FOR UPDATE (Tom)
>
> What did this fix? Does SELECT FOR UDPATE now work whereas it didn't use
> to? => "SELECT ... FOR UPDATE now works in PL/pgSQL"

Part of the problem here is that I have to guess from the commit message
as to what was actually changed. The entries have to be:

o concise
o understandable to novices
o combine entries fixing the same problem

I could use some more information on this one. I should add that
certain committers, particularly to interfaces, have commit messages
that just say "Committed patch from Fred" and this does not help me
generate a proper HISTORY file. Usually, copying something from the
original message helps.

>
> | Fix for PL/pgSQL PERFORM returning multiple rows (Tom)
>
> What did this fix? Can you return multiple rows now or does it merely
> give an error message that you cannot where it used to crash?

Again, I don't know.

> | Fix for inherited CHECK constraints (Stephan Szabo)
>
> ditto

I don't know the details. Can you give them to me?

>
> | PL/pgSQL Allow IS and FOR in cursors (Bruce)
>
> If I didn't happen to know exactly what this meant, I wouldn't have a
> clue.

I can fix this one:

PL/pgSQL Allow IS and FOR keywords in cursors, for compatibility (Bruce)

> | Allow NULL to appear at beginning/end based on ORDER BY (Tom)
>
> It doesn't "allow", it just "does".

Uh, yes, this is better:

Make NULL appear at beginning/end based on ORDER BY (Tom)

> | Pltcl add spi_lastoid capability (bob(at)redivi(dot)com)
>
> Capability = command, function, type, ...?

Got it, capability -> function:

Pltcl add spi_lastoid function (bob(at)redivi(dot)com)
>
> | Allow column renaming in views
>
> ALTER VIEW foo RENAME COLUMN -- huh?

Actually, yes, it modifies the AS label of the column. Was that what
you meant?

create view x as select * from pg_class;
alter table x rename column relname to jj;
select jj from x;

I suppose it didn't work before.

> | New option to output SET SESSION AUTHORIZATION commands (Peter E)
>
> Option to what to output where?

I now see the entire command was added in 7.2. I missed the earlier CVS
commit:

New SET SESSION AUTHORIZATION command (Peter E)

> | New postgresql.conf option to enable/disable "col = NULL" comparisons
>
> This is not correct.

Uh, it isn't? Can you give me some new text?

>
> | Cachability fixes (Thomas, Tom)
>
> I don't think cachability as such was "fixed", or even "changed". The
> item probably related to some iscacheable pg_proc entries which were
> temporarily broken.

Do you have other wording? Seems there were was a cachability bug
report and we "fixed" it in the catalogs.

> The categories Bug Fixes, Enhancements, Types, Performance, Interfaces,
> Source Code could be split better, and they're not used very consistently.
> An example from each category that doesn't fit:
>
> Bug Fixes: Disallow access to pg_statistic for non-super user (Tom)
> This was not a bug, but a consequence of a change.

I considered it a bug. If there was a salary column, any user in 7.1
could see the max value in the column. Seemed like a security bug to
me.

>
> Enhancements: Fix TCL COPY TO/FROM (ljb)
> If it is "fixed" then it was broken before.

Now:

Add TCL COPY TO/FROM (ljb)

Fixed. :-)

> Types: New function bit_length() (Peter E)
> No comment.

Uh, I started to put some of the type-specific additions into Types. Is
that OK? Particularly the multi-byte ones so they are all in one place.

>
> Performance: Dynahash portability improvements (Tom)

Good point. Moved.

>
> Interfaces: Obviously, anything done in the interfaces is also either a
> bug fix or an enhancement. And what exactly constitutes an interface is
> not clear to me.

Not clear to me either. I wanted to get jdbc and odbc into separate
lists because they are so large. Seemed like a good idea.

> Source code: Remove OID's from some system tables (Tom)
> Maybe this is an enhancement.

Uh, yes.

> Some changes are "must know", because they are incompatible, such as
>
> | Load pg_hba.conf only on startup and SIGHUP (Bruce)
>
> This should be made clear somewhere.

Added to Migration section:

Also, pg_hba.conf only loads on SIGHUP now.

> Finally,
>
> | Remove configure --enable-pltcl-utf option
>
> There was never such an option in a previous release.

Oh, did that come in and out in 7.2? Removed.

Let me know what else you see. Thanks.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
/usr/local/bin/mime: cannot create /dev/ttyp5: permission denied

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jean-Michel POURE 2001-10-29 19:10:32 Re: Serious performance problem
Previous Message Tom Lane 2001-10-29 18:19:37 Re: Regression error on unixware 7 and open unix 8