Re: [HACKERS] [GENERAL] PlPython
elein kirjutas T, 24.06.2003 kell 00:42: There is a realtively clean hack one can use to convert plpython functions to plpythonu manually - just rename the language for the time of loading functions - do as superuser update pg_language set lanname = 'plpython' where lanname = 'plpythonu'; LOAD YOUR Pl/Python FUNCTIONS ; update pg_language set lanname = 'plpythonu' where lanname = 'plpython'; > PS: I've built and tested the plpython patch against > 7.3.2 and am happy it does not affect the features I count > on. As it should. The untrusted language gives you *more* power, not less. The untrusted status means that the user has to be trusted to use that much power. Hannu ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [GENERAL] PlPython
I thought there would be a relatively clear way to alias them both to the same language library for a release or two. But I see your point on transitioning. Clear notice is really important. plpython should be phased out if it is not replaced within a release or two. If only the change could be transparent to those people who are not using any untrusted features. Maybe it is better to break everyone's plpython functions in 7.4. That would certainly make sure everyone heard of the change from trusted to untrusted. But explanations of what exactly that means should also be included in the release notes. elein PS: I've built and tested the plpython patch against 7.3.2 and am happy it does not affect the features I count on. I'd do it against the development release but I can't get it to build (for other reasons). On Monday 23 June 2003 13:53, Tom Lane wrote: > elein <[EMAIL PROTECTED]> writes: > > For 7.4 (which I expect is the patch's target) it might be > > best to make both names point to the same thing with a > > clear release note that says that they are the same thing > > and that plpython[u] is now untrusted. > > I don't know any way to actually do that, though. If we put two entries > in pg_language then functions created in plpython will stay associated > with that entry. That'd probably be the worst of all possible worlds, > since a person looking at pg_language would quite reasonably assume that > plpython was still trusted and the untrusted plpythonu was just an > addition. (Especially if he happened to know that such an addition was > planned long ago.) You could shoot yourself in the foot pretty badly > with such a misunderstanding :-( > > The behavior that I think would be most useful would be to automatically > transpose CREATE FUNCTION ... LANGUAGE "plpython" into CREATE FUNCTION > ... LANGUAGE "plpythonu". Which we could do with an ugly hack in CREATE > FUNCTION (ugly, but no worse than things we've done to index opclass > names, for example). But it could be too confusing. > > regards, tom lane > > -- = [EMAIL PROTECTED] Database Consulting www.varlena.com PostgreSQL General Bitshttp:/www.varlena.com/GeneralBits/ "Free your mind the rest will follow" -- en vogue ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [GENERAL] PlPython
For 7.4 (which I expect is the patch's target) it might be best to make both names point to the same thing with a clear release note that says that they are the same thing and that plpython[u] is now untrusted. That will give people a bit a time to reload their existing functions. elein On Sunday 22 June 2003 15:29, Tom Lane wrote: > Kevin Jacobs <[EMAIL PROTECTED]> writes: > > Attached is a patch that removes all of the RExec code from plpython from > > the current PostgreSQL CVS. In addition, plpython needs to be changed to an > > untrusted language in createlang. > > I am inclined to rename plpython to plpythonu, by analogy to pltclu. > The advantage of doing so is that (a) the name change makes it somewhat > more obvious that there's a fundamental behavioral change, and (b) > assuming that the Python folk someday figure out a secure version of > RExec, we'd want to reinstitute the trusted version of plpython, but > perhaps not take away the untrusted one. > > On the other hand, this would create headaches for people who are trying > to load dump files that declare plpython or contain plpython-language > functions. I can't think of any non-kluge solution to this (kluge > solutions would include putting special-case code into CREATE FUNCTION > to change 'plpython' to 'plpythonu' ...) > > Comments? > > regards, tom lane > > ---(end of broadcast)--- > TIP 9: the planner will ignore your desire to choose an index scan if your > joining column's datatypes do not match > > -- = [EMAIL PROTECTED] Database Consulting www.varlena.com PostgreSQL General Bitshttp:/www.varlena.com/GeneralBits/ "Free your mind the rest will follow" -- en vogue ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [GENERAL] PlPython
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Tom Lane wrote: > >> The behavior that I think would be most useful would be to automatically > >> transpose CREATE FUNCTION ... LANGUAGE "plpython" into CREATE FUNCTION > >> ... LANGUAGE "plpythonu". Which we could do with an ugly hack in CREATE > >> FUNCTION (ugly, but no worse than things we've done to index opclass > >> names, for example). But it could be too confusing. > > > You mean in gram.y? Yes, I think that is our only choice. > > Actually I think it should be in functioncmds.c. I moved the special > kluges for opclass names out of gram.y and into indexcmds.c awhile ago. > But that's just an implementation detail --- we really need to still be > thinking about whether this is the behavior we want or not. Someone > else made a fair point that such a kluge might not actually make life > any easier for reloading dump files. If we do it that way, then if a > non-superuser tries to CREATE FUNCTION ... LANGUAGE "plpython" it will > fail (not being trusted) and so he's got no hope of loading the dump > without editing anyway. If that's true, there's not much point in > introducing a hidden kluge. Well, it does fix the super-user case, so we have to tell non-super users to get their administrator to install it, which actually is the right solution anyway for non-super-user installs of plpython language modules anyway. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [GENERAL] PlPython
Bruce Momjian <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> The behavior that I think would be most useful would be to automatically >> transpose CREATE FUNCTION ... LANGUAGE "plpython" into CREATE FUNCTION >> ... LANGUAGE "plpythonu". Which we could do with an ugly hack in CREATE >> FUNCTION (ugly, but no worse than things we've done to index opclass >> names, for example). But it could be too confusing. > You mean in gram.y? Yes, I think that is our only choice. Actually I think it should be in functioncmds.c. I moved the special kluges for opclass names out of gram.y and into indexcmds.c awhile ago. But that's just an implementation detail --- we really need to still be thinking about whether this is the behavior we want or not. Someone else made a fair point that such a kluge might not actually make life any easier for reloading dump files. If we do it that way, then if a non-superuser tries to CREATE FUNCTION ... LANGUAGE "plpython" it will fail (not being trusted) and so he's got no hope of loading the dump without editing anyway. If that's true, there's not much point in introducing a hidden kluge. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [GENERAL] PlPython
Tom Lane wrote: > elein <[EMAIL PROTECTED]> writes: > > For 7.4 (which I expect is the patch's target) it might be > > best to make both names point to the same thing with a > > clear release note that says that they are the same thing > > and that plpython[u] is now untrusted. > > I don't know any way to actually do that, though. If we put two entries > in pg_language then functions created in plpython will stay associated > with that entry. That'd probably be the worst of all possible worlds, > since a person looking at pg_language would quite reasonably assume that > plpython was still trusted and the untrusted plpythonu was just an > addition. (Especially if he happened to know that such an addition was > planned long ago.) You could shoot yourself in the foot pretty badly > with such a misunderstanding :-( > > The behavior that I think would be most useful would be to automatically > transpose CREATE FUNCTION ... LANGUAGE "plpython" into CREATE FUNCTION > ... LANGUAGE "plpythonu". Which we could do with an ugly hack in CREATE > FUNCTION (ugly, but no worse than things we've done to index opclass > names, for example). But it could be too confusing. You mean in gram.y? Yes, I think that is our only choice. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [GENERAL] PlPython
elein <[EMAIL PROTECTED]> writes: > For 7.4 (which I expect is the patch's target) it might be > best to make both names point to the same thing with a > clear release note that says that they are the same thing > and that plpython[u] is now untrusted. I don't know any way to actually do that, though. If we put two entries in pg_language then functions created in plpython will stay associated with that entry. That'd probably be the worst of all possible worlds, since a person looking at pg_language would quite reasonably assume that plpython was still trusted and the untrusted plpythonu was just an addition. (Especially if he happened to know that such an addition was planned long ago.) You could shoot yourself in the foot pretty badly with such a misunderstanding :-( The behavior that I think would be most useful would be to automatically transpose CREATE FUNCTION ... LANGUAGE "plpython" into CREATE FUNCTION ... LANGUAGE "plpythonu". Which we could do with an ugly hack in CREATE FUNCTION (ugly, but no worse than things we've done to index opclass names, for example). But it could be too confusing. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
