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
