Thread: 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_dumpsfunctions no longer public executablelanguages 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,
Pennsylvania19073
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 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. 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, Pennsylvania19073
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