HISTORY updated for 7.3beta2
I have updated /HISTORY for 7.3beta2. Looking at the open items list, I
think we are ready for beta2 now.
---------------------------------------------------------------------------
P O S T G R E S Q L
7 . 3 O P E N I T E M S
Current at ftp://candle.pha.pa.us/pub/postgresql/open_items.
Source Code Changes
-------------------
Schema handling - ready? interfaces? client apps?
Drop column handling - ready for all clients, apps?
Fix BeOS, QNX4 ports
Fix AIX large file compile failure of 2002-09-11 (Andreas)
Get bison upgrade on postgresql.org for ecpg only (Marc)
Fix vacuum btree bug (Tom)
Fix client apps for autocommit = off
Fix clusterdb to be schema-aware
Change log_min_error_statement to be off by default (Gavin)
Fix return tuple counts/oid/tag for rules
Loading 7.2 pg_dumps
functions no longer public executable
languages no longer public usable
Add schema dump option to pg_dump
Add param for length check for char()/varchar()
Fix $libdir in loaded functions?
Make SET not start a transaction with autocommit off, document it
Add GRANT EXECUTE to all /contrib functions
On Going
--------
Security audit
Documentation Changes
---------------------
Document need to add permissions to loaded functions and languages
Move documation to gborg for moved projects
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
En Mon, 23 Sep 2002 01:26:25 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us> escribi�:
7 . 3 O P E N I T E M S
Fix clusterdb to be schema-aware
Please apply the patch attached and this should be solved.
--
Alvaro Herrera (<alvherre[a]atentus.com>)
"I think my standards have lowered enough that now I think 'good design'
is when the page doesn't irritate the living fuck out of me." (JWZ)
Attachments:
clusterdb2.patchapplication/octet-stream; name=clusterdb2.patchDownload
Index: clusterdb
===================================================================
RCS file: /projects/cvsroot/pgsql-server/src/bin/scripts/clusterdb,v
retrieving revision 1.3
diff -c -r1.3 clusterdb
*** clusterdb 2002/09/12 00:18:14 1.3
--- clusterdb 2002/09/23 08:19:52
***************
*** 153,159 ****
for db in $dbname
do
[ "$alldb" ] && echo "Clustering $db"
! query="SELECT nspname, pg_class.relname, pg_class_2.relname FROM pg_class, pg_class AS pg_class_2 JOIN pg_namespace ON (pg_namespace.oid=relnamespace), pg_index WHERE pg_class.oid=pg_index.indrelid AND pg_class_2.oid=pg_index.indexrelid AND pg_index.indisclustered"
if [ -z "$table" ]; then
tables=`${PATHNAME}psql $db $PSQLOPT -F: -P format=unaligned -t -c "$query"`
else
--- 153,159 ----
for db in $dbname
do
[ "$alldb" ] && echo "Clustering $db"
! query="SELECT nspname, pg_class.relname, pg_class_2.relname FROM pg_class, pg_class AS pg_class_2 JOIN pg_namespace ON (pg_namespace.oid=relnamespace), pg_index WHERE pg_class.oid=pg_index.indrelid AND pg_class_2.oid=pg_index.indexrelid AND pg_index.indisclustered AND pg_class.relowner=(SELECT usesysid FROM pg_user WHERE usename=current_user)"
if [ -z "$table" ]; then
tables=`${PATHNAME}psql $db $PSQLOPT -F: -P format=unaligned -t -c "$query"`
else
Bruce Momjian <pgman@candle.pha.pa.us> writes:
7 . 3 O P E N I T E M S
Loading 7.2 pg_dumps
functions no longer public executable
languages no longer public usable
Although it's reasonably easy to fix no-privileges problems for
functions after you load a dump, it occurs to me that the same does not
hold for PL languages. If a newly created language doesn't have USAGE
available to public, then any function definitions in your dump are
going to fail, if they belong to non-superusers.
I am thinking that the better course might be to have newly created
languages default to USAGE PUBLIC, at least for a release or two.
We might also consider letting newly created functions default to
EXECUTE PUBLIC. I think this is less essential, but a case could still
be made for it on backwards-compatibility grounds.
If you don't want to hard-wire that behavior, what about a GUC variable
that could be turned on while loading old dumps?
Comments?
regards, tom lane
Tom Lane wrote:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
7 . 3 O P E N I T E M S
Loading 7.2 pg_dumps
functions no longer public executable
languages no longer public usableAlthough it's reasonably easy to fix no-privileges problems for
functions after you load a dump, it occurs to me that the same does not
hold for PL languages. If a newly created language doesn't have USAGE
available to public, then any function definitions in your dump are
going to fail, if they belong to non-superusers.I am thinking that the better course might be to have newly created
languages default to USAGE PUBLIC, at least for a release or two.We might also consider letting newly created functions default to
EXECUTE PUBLIC. I think this is less essential, but a case could still
be made for it on backwards-compatibility grounds.
Yes, I am wondering if we should go one release with them open to give
people a chance to adjust, but actually, I don't understand how we could
do that effectively. Do we tell them to add GRANTs in 7.3 and tighten
it down in 7.4, and if we do that, will the GRANTs be recorded in
pg_dump properly?
To me a table contains data, while a function usually just causes an
action, and I don't see why an action has to be restricted (same with
language). I realize we have some actions that must be limited, like
clearing the stat collector, but the majority seem benign. Does the
standard require us to restrict their executability?
If you don't want to hard-wire that behavior, what about a GUC variable
that could be turned on while loading old dumps?
I think GUC is going to be confusing. Let's see if we can decide on a
good course first.
Well, we better decide something before we do beta2.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Tom Lane writes:
I am thinking that the better course might be to have newly created
languages default to USAGE PUBLIC, at least for a release or two.
That seems reasonable. Since everyone is supposed to use createlang,
that's the effective default anyway.
--
Peter Eisentraut peter_e@gmx.net
Peter Eisentraut <peter_e@gmx.net> writes:
Tom Lane writes:
I am thinking that the better course might be to have newly created
languages default to USAGE PUBLIC, at least for a release or two.
That seems reasonable. Since everyone is supposed to use createlang,
that's the effective default anyway.
Good point. I shall make it happen.
How do you feel about allowing functions to default to EXECUTE PUBLIC?
regards, tom lane
Hello!
On Mon, 23 Sep 2002, Tom Lane wrote:
I am thinking that the better course might be to have newly created
languages default to USAGE PUBLIC, at least for a release or two.We might also consider letting newly created functions default to
EXECUTE PUBLIC. I think this is less essential, but a case could still
be made for it on backwards-compatibility grounds.
Hm...M$ had proven this way is false. See BUGTRAQ about sp_* stories every
quarter.;)
If you don't want to hard-wire that behavior, what about a GUC variable
that could be turned on while loading old dumps?
Comments?
That seems to be more reasonable.
--
WBR, Yury Bokhoncovich, Senior System Administrator, NOC of F1 Group.
Phone: +7 (3832) 106228, ext.140, E-mail: byg@center-f1.ru.
Unix is like a wigwam -- no Gates, no Windows, and an Apache inside.
Tom Lane writes:
How do you feel about allowing functions to default to EXECUTE PUBLIC?
Less excited, but if it gets us to the point of no known problems during
upgrade we might as well do it.
--
Peter Eisentraut peter_e@gmx.net
Peter Eisentraut <peter_e@gmx.net> writes:
Tom Lane writes:
How do you feel about allowing functions to default to EXECUTE PUBLIC?
Less excited, but if it gets us to the point of no known problems during
upgrade we might as well do it.
Okay, I've changed the defaults for both languages and functions; if we
think of something better we can change it again ...
regards, tom lane