Thread: Quick Extensions Question
It's about dependences. If my extension requires a procedural language, will adding that language to the `requires` control key do what I think itshould do? If not, how should one require a PL? Come to think of it, how might I require other features that might not be included ina particular build, like xpath()? Thanks, David
"David E. Wheeler" <david@kineticode.com> writes:
> If my extension requires a procedural language, will adding that language to the `requires` control key do what I
thinkit should do?
No.
Probably in future the standard PLs will be packaged as extensions, and
then it will work. The main reason that it won't happen for 9.1 is that
right now we require superuser privilege to install an extension, which
would be a regression compared to the privilege requirements for
installing standard PLs in existing releases. And relaxing that
requirement is a research project :-(
regards, tom lane
On Mar 2, 2011, at 11:00 PM, Tom Lane wrote: > "David E. Wheeler" <david@kineticode.com> writes: >> If my extension requires a procedural language, will adding that language to the `requires` control key do what I thinkit should do? > > No. > > Probably in future the standard PLs will be packaged as extensions, and > then it will work. The main reason that it won't happen for 9.1 is that > right now we require superuser privilege to install an extension, which > would be a regression compared to the privilege requirements for > installing standard PLs in existing releases. And relaxing that > requirement is a research project :-( Okay. I guess the to do list should be updated? http://wiki.postgresql.org/wiki/Todo Best, David
Tom Lane <tgl@sss.pgh.pa.us> writes: > Probably in future the standard PLs will be packaged as extensions, and > then it will work. The main reason that it won't happen for 9.1 is that > right now we require superuser privilege to install an extension, which > would be a regression compared to the privilege requirements for > installing standard PLs in existing releases. And relaxing that > requirement is a research project :-( Meanwhile, is it possible to have CREATE LANGUAGE internally register an extension? It's a kludge but I somehow though I'd mention it. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> Probably in future the standard PLs will be packaged as extensions, and
>> then it will work. The main reason that it won't happen for 9.1 is that
>> right now we require superuser privilege to install an extension, which
>> would be a regression compared to the privilege requirements for
>> installing standard PLs in existing releases. And relaxing that
>> requirement is a research project :-(
> Meanwhile, is it possible to have CREATE LANGUAGE internally register an
> extension? It's a kludge but I somehow though I'd mention it.
Hmmm ... it definitely is a kluge, but ...
You'd need to work out how the CREATE OR REPLACE and DROP cases would
work.
regards, tom lane
Tom Lane <tgl@sss.pgh.pa.us> writes: >> Meanwhile, is it possible to have CREATE LANGUAGE internally register an >> extension? It's a kludge but I somehow though I'd mention it. > > Hmmm ... it definitely is a kluge, but ... > > You'd need to work out how the CREATE OR REPLACE and DROP cases would > work. Maybe the fever ain't gone far enough, but I'd just do nothing in the first case and internally cascade to the extension in the second case. In fact internally the drop case would be redirected on the extension and the dependencies would get rid of the PL, right? -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> You'd need to work out how the CREATE OR REPLACE and DROP cases would
>> work.
> Maybe the fever ain't gone far enough, but I'd just do nothing in the
> first case and internally cascade to the extension in the second case.
> In fact internally the drop case would be redirected on the extension
> and the dependencies would get rid of the PL, right?
Not sure it's that easy. I think DROP LANGUAGE can't assume that the
language it's been told to drop is extension-ified. (Even if we do this
for all the core ones, there are a dozen non-core ones that might not
all get with the program right away.) How do we make this work in a way
that covers both cases, but doesn't turn DROP LANGUAGE into a security
hole that lets non-superusers drop random extensions?
It may all work pretty easily, but I'm still caffeine-deprived so I'm
not sure ...
regards, tom lane
On Thu, Mar 3, 2011 at 10:31 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > It may all work pretty easily, but I'm still caffeine-deprived so I'm > not sure ... I think that it's not a good idea to devote too much energy to this problem right now, anyway. We have crammed a gigantic pile of code into the source tree in the last month, and there are bound to be bugs even in what we already have. We need to get that code out into the field in the form of alpha and beta releases and start getting it tested; and even apart from bugs, we need to get some field experience with it, so that we learn which things work well enough in practice and which things are really problems. Then we can come back to the table and engineer better solutions for 9.2. It is also important that we get to the point of being able to start accepting 9.2 patches on other topics as quickly as possible. Unless we do something radically different than what we have done in previous releases, we are now about to enter a ~4 month period during which there will be no CommitFests and very little 9.2 work underway, at least publicly. Even with the improvements we have made in getting CommitFests started and finished on time (the present case being, fortunately, an exception, and yeah I know it could have been a lot worse, but it could also have been better), the long quiet period that is required to get a release out the door is still problematic for many of our developers. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
[ slightly more awake now ... ]
I wrote:
> Not sure it's that easy. I think DROP LANGUAGE can't assume that the
> language it's been told to drop is extension-ified. (Even if we do this
> for all the core ones, there are a dozen non-core ones that might not
> all get with the program right away.)
No, wait, that's nonsense. With what you're talking about, there would
never be a non-extension-ified language, because CREATE LANGUAGE would
force it to be attached to an extension. So maybe that problem isn't
so hard after all.
However, what *is* looking a bit hard is dump/restore behavior. By
default, pg_dump would proceed to dump an installed language as a CREATE
EXTENSION command, and that would fail on restore, especially if you
were trying to restore as non superuser. The behavior of
--binary-upgrade would be differently unpleasant: it would make the
extension, then try to CREATE LANGUAGE, and that would fail because the
extension name already exists. No doubt we could kluge those behaviors
too, but it's starting to look pretty messy.
On the whole I'd rather spend time trying to fix the real problem, which
is allowing CREATE EXTENSION to non-superusers. The general case of
that looks quite hard to me, but maybe we could get something that works
for the single case of an extension containing just a language.
regards, tom lane
Robert Haas <robertmhaas@gmail.com> writes:
> I think that it's not a good idea to devote too much energy to this
> problem right now, anyway. [ we need to get to beta ASAP, instead ]
I hear you, but once we get to beta, or even the last alpha, it's going
to be very hard to make changes that would interfere with people doing
upgrades or dump/restores. If we don't do something about the language-
as-extension situation right now, the window will be closed until 9.2.
Most of the other things that are on our plates for beta are internal
changes that would be unlikely to break the upgrade path for beta
testers.
You may well be right that there's no way to fix this with an amount of
effort that would be appropriate to spend now, but I don't want to just
walk away from the problem without considering whether there is a way
that we can fix it with a day or so's additional effort.
regards, tom lane
Tom Lane <tgl@sss.pgh.pa.us> writes: > Not sure it's that easy. I think DROP LANGUAGE can't assume that the > language it's been told to drop is extension-ified. (Even if we do this If CREATE LANGUAGE creates an extension of the same name, then DROP LANGUAGE can assume that there's an extension of the same name, right? > for all the core ones, there are a dozen non-core ones that might not > all get with the program right away.) How do we make this work in a way > that covers both cases, but doesn't turn DROP LANGUAGE into a security > hole that lets non-superusers drop random extensions? We could check that the extension named the same as the language only contains one object of class pg_language. > It may all work pretty easily, but I'm still caffeine-deprived so I'm > not sure ... It does not look like a big deal to me either. If you don't have the time too, I could propose a patch. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
On Thu, Mar 3, 2011 at 11:19 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> I think that it's not a good idea to devote too much energy to this >> problem right now, anyway. [ we need to get to beta ASAP, instead ] > > I hear you, but once we get to beta, or even the last alpha, it's going > to be very hard to make changes that would interfere with people doing > upgrades or dump/restores. If we don't do something about the language- > as-extension situation right now, the window will be closed until 9.2. So what? AFAIK the extension patch hasn't broken anything here that used to work. People can still install languages the way they always have. What we're talking about here is a way of installing languages that is arguably nicer than what they are doing now. The window for feature enhancements is already closed until 9.2, unless you want to go back and start working through every patch we marked Returned with Feedback during this last CommitFest. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 03.03.2011 18:30, Robert Haas wrote: > On Thu, Mar 3, 2011 at 11:19 AM, Tom Lane<tgl@sss.pgh.pa.us> wrote: >> Robert Haas<robertmhaas@gmail.com> writes: >>> I think that it's not a good idea to devote too much energy to this >>> problem right now, anyway. [ we need to get to beta ASAP, instead ] >> >> I hear you, but once we get to beta, or even the last alpha, it's going >> to be very hard to make changes that would interfere with people doing >> upgrades or dump/restores. If we don't do something about the language- >> as-extension situation right now, the window will be closed until 9.2. > > So what? AFAIK the extension patch hasn't broken anything here that > used to work. People can still install languages the way they always > have. What we're talking about here is a way of installing languages > that is arguably nicer than what they are doing now. IMHO the main advantage of having languages as extensions is that you could define a dependency on a language. We've been talking about PLs, but what about the other thing David asked: could we have extension entries for compile-time options like SSL or libxml, so that you could define a dependency on them? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
On Thu, Mar 3, 2011 at 11:39 AM, Aidan Van Dyk <aidan@highrise.ca> wrote: > No, what is being talked about isn't intended as a "way of installing > languages that is ... nicer". What is being talked about is allowing > an "Extension" that is being installed know that it's going to blow up > because it's required language (plpgsql, for instance) isn't > installed. > > Maybe it's a problem with extensions that isn't easily solvable, but > that means extension authors are going to have a readme in their > extension with the followign text: > EXTENSION "mystuff" requires that pl/pgsql be installed in the > database. There is no way for the extension to check this before > it is installed, so make sure it's installed, or be prepared to > cope with errors during the installation. > > And make sure you don't try and drop pl/pgsql language when > the extension is installed either. > > > Maybe that's enough for 9.1. Well, in 9.0, what'll happen is you'll type psql -f somefile.sql and it'll spit out a stream of error messages if things aren't in the prerequisite state. Unless you happen to have taken the precaution of wrapping the whole thing in a transaction, you may end up with the extension half-installed and some fun manual cleanup to do. I'm not going to argue that this is perfect, but it is already better than it was. The extensions patch didn't change much between mid-Decemeber when we wrapped up CF#3 and early February when Tom picked it up. If he wanted to have a chance to do lots more refinement after the initial commit, he had the means within his grasp: he could have picked it up in December. It is no more fair for Tom to hold up this release to work on extensions than it is for Simon to hold it up to work on sync rep. Jeff Davis would have loved to get range types in, Alvaro would have liked to do finish his work on foreign key locks, and there are other examples as well. We can't expect anyone to be willing to step aside graciously when time has expired unless everyone is willing to do it. By the way, I don't question Tom's decision to leave this patch until February. He worked on other things. Who am I to say that they were any less valuable than this? But you can't have your cake and eat it too. There's a part of me that wonders whether we'd get the same number of features per release if we shortened the release cycle by one CommitFest. Most large patches get done in 2 or 3 CommitFests, so it would still be entirely reasonable to get a major feature done in one release. Right now we seem to have two classes of people: the ones who start working at the beginning of the cycle, and are done by CF#2/#3, and the ones who start at the end of the cycle, and hold things up at the end. Neither group would get any less done on a shorter cycle. Contrariwise I bet if we went to 5 CommitFests we'd see only a slight increase in patches - they'd just be spread out over more calendar time. It's already the case that the middle two CommitFests are smaller than the first and last. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Thu, Mar 3, 2011 at 4:30 PM, Robert Haas <robertmhaas@gmail.com> wrote: > So what? AFAIK the extension patch hasn't broken anything here that > used to work. People can still install languages the way they always > have. What we're talking about here is a way of installing languages > that is arguably nicer than what they are doing now. The window for > feature enhancements is already closed until 9.2, unless you want to > go back and start working through every patch we marked Returned with > Feedback during this last CommitFest. No, what is being talked about isn't intended as a "way of installing languages that is ... nicer". What is being talked about is allowing an "Extension" that is being installed know that it's going to blow up because it's required language (plpgsql, for instance) isn't installed. Maybe it's a problem with extensions that isn't easily solvable, but that means extension authors are going to have a readme in their extension with the followign text: EXTENSION "mystuff" requires that pl/pgsql be installed in the database. There is noway for the extension to check this before it is installed, so make sure it's installed, or be prepared to cope witherrors during the installation. And make sure you don't try and drop pl/pgsql language when the extension is installed either. Maybe that's enough for 9.1. a. -- Aidan Van Dyk Create like a god, aidan@highrise.ca command like a king, http://www.highrise.ca/ work like a slave.
Tom Lane <tgl@sss.pgh.pa.us> writes: > On the whole I'd rather spend time trying to fix the real problem, which > is allowing CREATE EXTENSION to non-superusers. The general case of > that looks quite hard to me, but maybe we could get something that works > for the single case of an extension containing just a language. Then, what about a control file property to cover that? pl_language = plpgsql Then when running the script any object attached to the extension that is not a 'pg_catalog.pg_language'::regclass is an ERROR. And only when the pl_language property is used then the superuser-only check is bypassed. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes: > We've been talking about PLs, but what about the other thing David asked: > could we have extension entries for compile-time options like SSL or libxml, > so that you could define a dependency on them? Then those should be marked "System" and only get displayed with \dxS, or this will completely bloat the extension listings. Also if we get there, what about listing all the SQL Standard Features (optional only maybe) that are provided by the server? Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
On Mar 3, 2011, at 9:47 AM, Dimitri Fontaine wrote: > Then, what about a control file property to cover that? > > pl_language = plpgsql > > Then when running the script any object attached to the extension that > is not a 'pg_catalog.pg_language'::regclass is an ERROR. And only when > the pl_language property is used then the superuser-only check is > bypassed. More simply, I think there are two kinds of dependencies: * Other extensions * Core features Notwithstanding that PLs might be extensions, now or in the future, the necessity to require other stuff from core, likelibxml support or SSL, together with your example, leads me to think that we ought to think about having two ways ofspecifying dependencies: requires and core_requires. The latter might look something like: core_requires = plpgsql libxml The downside of course is that then there would need to be a second infrastructure for tracking core dependencies, and itwould need to be kept up-to-date. But I think something like this will be essential -- even if it only supports core PLsfor now. Best, David
On Mar 3, 2011, at 9:55 AM, Dimitri Fontaine wrote: > Then those should be marked "System" and only get displayed with \dxS, > or this will completely bloat the extension listings. Also if we get > there, what about listing all the SQL Standard Features (optional only > maybe) that are provided by the server? I think server version is sufficient for this. If we go with my previous proposal, I might add something like this to theexplanation extension I released on PGXN last week: core_requires = 9.0, plpgsql, libxml Best, David
"David E. Wheeler" <david@kineticode.com> writes: > core_requires = 9.0, plpgsql, libxml As soon as you get there you need an or operator to be able to say 9.0 | 9.1, or maybe some comparison operators to say >= 9.0. Remember that about all extensions we have are source-compatible with many different releases of PostgreSQL. So having the PostgreSQL server itself as an extension so that you can require it is 9.2 material at best in my opinion. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
On Mar 3, 2011, at 10:12 AM, Dimitri Fontaine wrote: > "David E. Wheeler" <david@kineticode.com> writes: >> core_requires = 9.0, plpgsql, libxml > > As soon as you get there you need an or operator to be able to say 9.0 | > 9.1, or maybe some comparison operators to say >= 9.0. Remember that > about all extensions we have are source-compatible with many different > releases of PostgreSQL. We'd just start by saying a number means >=. > So having the PostgreSQL server itself as an extension so that you can > require it is 9.2 material at best in my opinion. That sounds silly. It's clearly not an extension. David
On Thu, Mar 3, 2011 at 12:56 PM, David E. Wheeler <david@kineticode.com> wrote: > More simply, I think there are two kinds of dependencies: > > * Other extensions > * Core features > > Notwithstanding that PLs might be extensions, now or in the future, the necessity to require other stuff from core, likelibxml support or SSL, together with your example, leads me to think that we ought to think about having two ways ofspecifying dependencies: requires and core_requires. The latter might look something like: > > core_requires = plpgsql libxml Not a bad thought, but you might also need to require at least a certain version of libxml. RPMs have a whole grammar for dependencies of this sort, and it is both complicated and very useful. You can say things like: Requires: package Requires: package >= minversion Requires: package <= maxversion Requires: package = exactversion The usefulness of the first two should be obvious, but the third and fourth are needed as well. For example, the kernel header version must exactly match the kernel version. I don't know 100% for certain that we're going to need those cases here as well, but I wouldn't bet against it. An RPM can also provide a certain capability: Provides: WonderfulGoodStuff And some other RPM can then depend on that capability. I think it's important that we don't get too confident that we've solved this problem in its full generality. I very much doubt that that's the case. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Mar 3, 2011, at 10:22 AM, Robert Haas wrote: > Requires: package > Requires: package >= minversion > Requires: package <= maxversion > Requires: package = exactversion > > The usefulness of the first two should be obvious, but the third and > fourth are needed as well. In the long term, perhaps. But for right now, just >= would address 90% of the problem. That's all CPAN modules have, andwhile it's occasionally annoying, it's *very* occasionally. > I think it's important that we don't get too confident that we've > solved this problem in its full generality. I very much doubt that > that's the case. Who said anything about full generality? I'm interested in a 90% (or even 99%) solution. David
On Thu, Mar 3, 2011 at 1:30 PM, David E. Wheeler <david@kineticode.com> wrote: > On Mar 3, 2011, at 10:22 AM, Robert Haas wrote: > >> Requires: package >> Requires: package >= minversion >> Requires: package <= maxversion >> Requires: package = exactversion >> >> The usefulness of the first two should be obvious, but the third and >> fourth are needed as well. > > In the long term, perhaps. But for right now, just >= would address 90% of the problem. That's all CPAN modules have, andwhile it's occasionally annoying, it's *very* occasionally. > >> I think it's important that we don't get too confident that we've >> solved this problem in its full generality. I very much doubt that >> that's the case. > > Who said anything about full generality? I'm interested in a 90% (or even 99%) solution. It's pretty important that we don't design ourselves into a corner here. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Mar 3, 2011, at 10:32 AM, Robert Haas wrote: >> Who said anything about full generality? I'm interested in a 90% (or even 99%) solution. > > It's pretty important that we don't design ourselves into a corner her Which is why my suggestion is pretty much free from any design. Just a list of dependencies, with only a server version number.No other syntax at all. It can be added later. David
"David E. Wheeler" <david@kineticode.com> wrote: > On Mar 3, 2011, at 10:32 AM, Robert Haas wrote: >> It's pretty important that we don't design ourselves into a >> corner her > > Which is why my suggestion is pretty much free from any design Now you're scaring me. I read that as "the proposed design is free from the influence of any design effort." That's precisely how you can find yourself standing in a corner with wet paint on the floor all around you. At a minimum you would need to specify the format of the dependency list and either some header and or terminator or some specification of something which *can't* be in the list. It would be ironic if our extensions configuration wasn't extensible. -Kevin
On Mar 3, 2011, at 10:49 AM, Kevin Grittner wrote: >> Which is why my suggestion is pretty much free from any design > > Now you're scaring me. I read that as "the proposed design is free > from the influence of any design effort." No. Just as simple as possible. > That's precisely how you > can find yourself standing in a corner with wet paint on the floor > all around you. But if the paint were made with chocolate, would you care? > At a minimum you would need to specify the format of the dependency > list and either some header and or terminator or some specification > of something which *can't* be in the list. It would be ironic if > our extensions configuration wasn't extensible. I'm talking about a hard-coded list of things that can go on the list, core items, simply separated by commas (or howeverthe postgresql.conf format supports a list of items). No external dependencies (like the particular version of libxml2)or any version numbers at all, aside from the server itself. Best, David
"David E. Wheeler" <david@kineticode.com> writes:
> On Mar 3, 2011, at 10:32 AM, Robert Haas wrote:
>>> Who said anything about full generality? I'm interested in a 90% (or even 99%) solution.
>>
>> It's pretty important that we don't design ourselves into a corner her
> Which is why my suggestion is pretty much free from any design. Just a list of dependencies, with only a server
versionnumber. No other syntax at all. It can be added later.
I basically agree with Robert that "requires = 9.1" is entirely useless.
There's next to no scenario where an extension author wouldn't really
be wanting to write "requires >= 9.1" instead. And to do that, we have
to solve the whole version-number-comparison problem that we worked so
hard to dodge before. So this all looks to me like something that needs
considerably more thought than we can devote to it for 9.1.
regards, tom lane
On Mar 3, 2011, at 10:54 AM, Tom Lane wrote: >> Which is why my suggestion is pretty much free from any design. Just a list of dependencies, with only a server versionnumber. No other syntax at all. It can be added later. > > I basically agree with Robert that "requires = 9.1" is entirely useless. > There's next to no scenario where an extension author wouldn't really > be wanting to write "requires >= 9.1" instead. And to do that, we have > to solve the whole version-number-comparison problem that we worked so > hard to dodge before. So this all looks to me like something that needs > considerably more thought than we can devote to it for 9.1. I'm saying that core_requires = 9.1.0, libxml, plpgsql Means >= 9.1.0. That = is an assignment operator, not comparison. And this is the *only* version number I'd specify, thecore version number, of which the core has perfect control of how things are compared (pg_version()). Best, David
"David E. Wheeler" <david@kineticode.com> writes:
> On Mar 3, 2011, at 10:54 AM, Tom Lane wrote:
>> I basically agree with Robert that "requires = 9.1" is entirely useless.
> I'm saying that
> core_requires = 9.1.0, libxml, plpgsql
> Means >= 9.1.0.
That's not a design, that's just a very arbitrary kluge. And it doesn't
solve anything at all that we need to solve today, because you can
already assume that you're running on >= 9.1 just by the fact that
you're writing an extension. Having a solution for this in time for
9.2 will be plenty soon enough.
BTW, I don't see any good reason to distinguish "core" requires from
non-core. If anything, the spirit of an extension proposal should be
trying to reduce the distinction between "core" stuff and "not-core"
stuff, since part of the point of extensions is that features might
migrate across that boundary.
regards, tom lane
On Mar 3, 2011, at 11:09 AM, Tom Lane wrote: > That's not a design, that's just a very arbitrary kluge. And it doesn't > solve anything at all that we need to solve today, because you can > already assume that you're running on >= 9.1 just by the fact that > you're writing an extension. Having a solution for this in time for > 9.2 will be plenty soon enough. Fair enough. > BTW, I don't see any good reason to distinguish "core" requires from > non-core. If anything, the spirit of an extension proposal should be > trying to reduce the distinction between "core" stuff and "not-core" > stuff, since part of the point of extensions is that features might > migrate across that boundary. Okay. My only concern on that front, with regards to a future design, is how things will be reserved. I suppose that couldbe got 'round by preserving things starting with, say, "pg-" or "pg:" as core features. So if I released an extensioncalled "xslt", it wouldn't conflict with the core xslt "extension". Or else core "extensions" would just have theirnames implicitly reserved. FWIW, extension names are required to be unique on PGXN. So no two people can have an extension named "foo". I'd like toget a list of core "extensions" reserved in the code soon so that no one tries to uploaded "plperl", for example. Whatmight such a list look like? Just PLs plus ./configure options (pam, ldap, bonjour, etc.) plus "postgresql" itself, ofcourse? Best, David
Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes: > Tom Lane <tgl@sss.pgh.pa.us> writes: >> On the whole I'd rather spend time trying to fix the real problem, which >> is allowing CREATE EXTENSION to non-superusers. The general case of >> that looks quite hard to me, but maybe we could get something that works >> for the single case of an extension containing just a language. > > Then, what about a control file property to cover that? > > pl_language = plpgsql > > Then when running the script any object attached to the extension that > is not a 'pg_catalog.pg_language'::regclass is an ERROR. And only when > the pl_language property is used then the superuser-only check is > bypassed. Well and of course as soon as one language is registered, new ones are an ERROR too. -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> On the whole I'd rather spend time trying to fix the real problem, which
>> is allowing CREATE EXTENSION to non-superusers. The general case of
>> that looks quite hard to me, but maybe we could get something that works
>> for the single case of an extension containing just a language.
> Then, what about a control file property to cover that?
> pl_language = plpgsql
That doesn't fix the permissions problem, it's just a special-case
wart for PLs.
However, it does strike me that there is one simple case we could
support without a great deal of sweat. Namely, what if we allow
non-superusers to create an extension if all the commands in the script
are ones they could execute anyway? In particular, an extension
containing only CREATE LANGUAGE would work for exactly those users
who could execute CREATE LANGUAGE under the existing dispensations.
This might also make it less painful to use extensions that consist
purely of SQL (no underlying C functions).
This special case avoids two of the nastier problems that have been
bugging me with respect to the general case:
1. We don't have to worry about somehow kluging the permissions checks
for commands executed within the script, as we would have to do to
let a non-superuser create an extension that includes C functions for
instance.
2. We aren't opening a Pandora's box of security vulnerabilities, as
would certainly happen if extension scripts that effectively have
superuser privs were to be executed in an environment under the control
of a malicious non-superuser.
Offhand I don't see any security risks in this type of feature.
We'd be letting non-superusers examine the extension directory,
but we have enough safeguards in place already to be sure they
can't see the rest of the filesystem via the extension commands.
In the simplest form we could implement this by just removing the
superuser() check in CREATE EXTENSION. But then people who tried
to load a superuser-only extension would get a permissions failure
on some random command within the extension, which might be thought
less than user-friendly. Also it might be good to have a more
explicit marking of superuser-only extensions. So I'm thinking it
might be best to invent a control file property along the lines of
superuser = false -- default is true
which would presently do nothing except control whether to make a
superuser() permissions check before running the script. (In future
it might do more, but only after a lot of careful thought.)
We'd also have to fix ALTER EXTENSION and DROP EXTENSION to check
for extension ownership instead of superuserness, but that would
be simple enough, since I already insisted on an extowner column ;-)
This looks like it would be at most a few hours' work to change,
and it would enable creation of extensions for the built-in languages
that can be loaded with the same permissions as before. It would
not do anything towards allowing non-superusers to load languages that
aren't listed in pg_pltemplate, but it doesn't make things any worse
for non-core languages either: they can make extensions that are
superuser-loadable, which is the same permissions situation they are
in now.
Comments?
regards, tom lane
On Mar 3, 2011, at 1:31 PM, Tom Lane wrote: > However, it does strike me that there is one simple case we could > support without a great deal of sweat. Namely, what if we allow > non-superusers to create an extension if all the commands in the script > are ones they could execute anyway? In particular, an extension > containing only CREATE LANGUAGE would work for exactly those users > who could execute CREATE LANGUAGE under the existing dispensations. > This might also make it less painful to use extensions that consist > purely of SQL (no underlying C functions). Now see here? THAT's what I'm talking about! > This looks like it would be at most a few hours' work to change, > and it would enable creation of extensions for the built-in languages > that can be loaded with the same permissions as before. Would that time include having extension records for the core PLs, created when you CREATE LANGUAGE and removed when youDROP LANGUAGE? > It would > not do anything towards allowing non-superusers to load languages that > aren't listed in pg_pltemplate, but it doesn't make things any worse > for non-core languages either: they can make extensions that are > superuser-loadable, which is the same permissions situation they are > in now. > > Comments? I assume that non-core PLs must be installed by a superuser? And if so, then they could be distributed as extensions withsuperuser = true? I think this is awesome. Love it, especially for SQL-only extensions (of which I expect there will be many in the comingyears). Of course, this doesn't address how to make compile-time options pre-requisites, but I think that's a somewhat less importantissue, frankly. I can modify the explanation extension install script to throw an exception of xpath isn't installed,for example. Kind of a PITA, but do-able. Best, David
Tom Lane <tgl@sss.pgh.pa.us> wrote: > what if we allow non-superusers to create an extension if all the > commands in the script are ones they could execute anyway? +1 The supporting detail all made sense to me. To put it another way, why would you want to *bar* someone from executing a set of statements they have authority to execute, just because someone gathered them together in an extension? -Kevin
"David E. Wheeler" <david@kineticode.com> writes:
> On Mar 3, 2011, at 1:31 PM, Tom Lane wrote:
>> This looks like it would be at most a few hours' work to change,
>> and it would enable creation of extensions for the built-in languages
>> that can be loaded with the same permissions as before.
> Would that time include having extension records for the core PLs, created when you CREATE LANGUAGE and removed when
youDROP LANGUAGE?
Extensions yes, but not managed with those commands. You'd have to
switch over to saying "CREATE/DROP EXTENSION plpgsql", etc. The LANGUAGE
commands themselves would now only occur within those extension
scripts.
BTW, a fine point I didn't mention in the previous summary is that if
CREATE LANGUAGE within an extension script creates language support
functions pursuant to what it finds in pg_pltemplate, those functions
should be marked as belonging to the extension, so that they'd get
dropped during DROP EXTENSION. I'm not sure whether the path of control
is such that that'd happen today, but if it doesn't we'd need to tweak
things.
> I assume that non-core PLs must be installed by a superuser?
Right. That's true already, because only a superuser can do the
unvetted 'CREATE FUNCTION ... LANGUAGE c' commands that are necessary
for installing a PL not known to pg_pltemplate. I would like to get
rid of pg_pltemplate eventually (in favor of trusting commands coming
from an extension script), but we're not there yet.
> And if so, then they could be distributed as extensions with superuser = true?
Right.
regards, tom lane
On Mar 3, 2011, at 2:16 PM, Tom Lane wrote: > Extensions yes, but not managed with those commands. You'd have to > switch over to saying "CREATE/DROP EXTENSION plpgsql", etc. The LANGUAGE > commands themselves would now only occur within those extension > scripts. Ah, I see. So if someone installed a PL with CREATE LANGUAGE and my extension requires that, PL, the requirement will notappear to be fulfilled. Kind of a bummer. Maybe add a note to CREATE LANGUAGE suggesting the use of CREATE EXTENSION,instead? Or perhaps createlang could be made to create the extension instead? That would probably mostly solvethe problem. > BTW, a fine point I didn't mention in the previous summary is that if > CREATE LANGUAGE within an extension script creates language support > functions pursuant to what it finds in pg_pltemplate, those functions > should be marked as belonging to the extension, so that they'd get > dropped during DROP EXTENSION. I'm not sure whether the path of control > is such that that'd happen today, but if it doesn't we'd need to tweak > things. Makes sense. > Right. That's true already, because only a superuser can do the > unvetted 'CREATE FUNCTION ... LANGUAGE c' commands that are necessary > for installing a PL not known to pg_pltemplate. I would like to get > rid of pg_pltemplate eventually (in favor of trusting commands coming > from an extension script), but we're not there yet. That sounds like a decent plan. I can see we're getting a number of To-Dos for 9.2 out of the extension work. Someone gotthe enumerated somewhere? >> And if so, then they could be distributed as extensions with superuser = true? > > Right. Great, thanks! David
"David E. Wheeler" <david@kineticode.com> writes:
> On Mar 3, 2011, at 2:16 PM, Tom Lane wrote:
>> Extensions yes, but not managed with those commands. You'd have to
>> switch over to saying "CREATE/DROP EXTENSION plpgsql", etc. The LANGUAGE
>> commands themselves would now only occur within those extension
>> scripts.
> Ah, I see. So if someone installed a PL with CREATE LANGUAGE and my
extension requires that, PL, the requirement will not appear to be
fulfilled. Kind of a bummer. Maybe add a note to CREATE LANGUAGE
suggesting the use of CREATE EXTENSION, instead?
Well, the recovery path at that point would involve "CREATE EXTENSION
plsomething FROM unpackaged". This doesn't seem to me to be any worse
than the messiness around upgrading contrib modules into extensions.
We would have to document it of course. But this is exactly analogous
to the case where you write an extension that "requires citext", and
then somebody complains because his 9.0-upgraded citext installation
doesn't satisfy the requires.
regards, tom lane
On Thu, Mar 3, 2011 at 4:31 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Comments? My only real concern about this is that someone might get confused about whether they are supposed to issue CREATE EXTENSION or CREATE LANGUAGE. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Mar 3, 2011 at 4:31 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Comments?
> My only real concern about this is that someone might get confused
> about whether they are supposed to issue CREATE EXTENSION or CREATE
> LANGUAGE.
It wouldn't really matter, up till the point when they tried to load an
extension that listed the language extension as a "requires". And then
they could fix it with CREATE EXTENSION ... FROM unpackaged. It's no
worse than the situation with contrib modules that haven't been upgraded
to extensions.
Also, to the extent that we can make all that "you forgot to upgrade it
to an extension" pain happen in 9.1, I think that's better than
spreading it over multiple releases. Which is what will happen if we
don't extension-ify languages till later.
regards, tom lane
Hi, Tom Lane <tgl@sss.pgh.pa.us> writes: > However, it does strike me that there is one simple case we could > support without a great deal of sweat. Namely, what if we allow > non-superusers to create an extension if all the commands in the script > are ones they could execute anyway? In particular, an extension > containing only CREATE LANGUAGE would work for exactly those users > who could execute CREATE LANGUAGE under the existing dispensations. > This might also make it less painful to use extensions that consist > purely of SQL (no underlying C functions). That what I had in mind for relaxing the superuser() checks, yes. > This special case avoids two of the nastier problems that have been > bugging me with respect to the general case: > > 1. We don't have to worry about somehow kluging the permissions checks > for commands executed within the script, as we would have to do to > let a non-superuser create an extension that includes C functions for > instance. That is a much more complex problem, and I think it would require that we have a way to mark shared objects as trustworthy. But we sure don't need that now. > 2. We aren't opening a Pandora's box of security vulnerabilities, as > would certainly happen if extension scripts that effectively have > superuser privs were to be executed in an environment under the control > of a malicious non-superuser. Yeah, I don't want setuid extension scripts either. > Offhand I don't see any security risks in this type of feature. > We'd be letting non-superusers examine the extension directory, > but we have enough safeguards in place already to be sure they > can't see the rest of the filesystem via the extension commands. Ok. > In the simplest form we could implement this by just removing the > superuser() check in CREATE EXTENSION. But then people who tried > to load a superuser-only extension would get a permissions failure > on some random command within the extension, which might be thought > less than user-friendly. Also it might be good to have a more > explicit marking of superuser-only extensions. So I'm thinking it > might be best to invent a control file property along the lines of > > superuser = false -- default is true > > which would presently do nothing except control whether to make a > superuser() permissions check before running the script. (In future > it might do more, but only after a lot of careful thought.) Well it's easy to read that the other way round. Is superuser = true means that I need to be a superuser or does it mean that the script will get run as superuser no matter what? Not a huge problem, but still. What about using the PL terminology here, and calling the property 'trusted' (default false, so you have to be a superuser to load them)? > We'd also have to fix ALTER EXTENSION and DROP EXTENSION to check > for extension ownership instead of superuserness, but that would > be simple enough, since I already insisted on an extowner column ;-) Hehe. We knew we would get there someday, it's been quicker than expected though :) > This looks like it would be at most a few hours' work to change, > and it would enable creation of extensions for the built-in languages > that can be loaded with the same permissions as before. It would > not do anything towards allowing non-superusers to load languages that > aren't listed in pg_pltemplate, but it doesn't make things any worse > for non-core languages either: they can make extensions that are > superuser-loadable, which is the same permissions situation they are > in now. In summary, +1 for this proposal. Also, do we want pg_upgrade to automatically do the create extension from unpackaged for us when upgrading a PL? I think it makes sense. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> In the simplest form we could implement this by just removing the
>> superuser() check in CREATE EXTENSION. But then people who tried
>> to load a superuser-only extension would get a permissions failure
>> on some random command within the extension, which might be thought
>> less than user-friendly. Also it might be good to have a more
>> explicit marking of superuser-only extensions. So I'm thinking it
>> might be best to invent a control file property along the lines of
>>
>> superuser = false -- default is true
>>
>> which would presently do nothing except control whether to make a
>> superuser() permissions check before running the script. (In future
>> it might do more, but only after a lot of careful thought.)
> Well it's easy to read that the other way round. Is superuser = true
> means that I need to be a superuser or does it mean that the script will
> get run as superuser no matter what? Not a huge problem, but still.
> What about using the PL terminology here, and calling the property
> 'trusted' (default false, so you have to be a superuser to load them)?
Hmm. I see your point, but "trusted" seems like it could just as easily
be misunderstood. Anybody have any other opinions about the color of
that bikeshed?
> In summary, +1 for this proposal.
I will be working on this today.
> Also, do we want pg_upgrade to automatically do the create extension
> from unpackaged for us when upgrading a PL? I think it makes sense.
That seems like a bit of a wart, but if it can be done in not too ugly a
way it's fine with me. I'll leave hacking pg_upgrade to somebody else
though.
I've thought of two other issues that need some discussion before we
can get very far with this:
1. What should pg_dump do with the preinstalled extension plpgsql?
We could put in a hardwired hack to not dump it, on the assumption that
it will be preinstalled in the destination database, but that seems a
bit ugly. When we decided to preinstall the language, we made pg_dump
emit CREATE OR REPLACE LANGUAGE so that the dump script would not fail
if the language was preinstalled. We don't have an equivalent command
for extensions, though. We can either invent one, or put a kluge into
pg_dump. Although I'm on record as generally disliking CREATE IF NOT
EXISTS, I think that having pg_dump emit "CREATE EXTENSION IF NOT EXISTS
foo" might be the best solution here. The reason why is that unlike the
case with other sorts of objects, you typically want the latest version
of an extension installed, not the one that was present in the source
database; so the dump script shouldn't be trying to force a particular
version to be installed, which is the semantics I'd expect of CREATE OR
REPLACE EXTENSION.
2. What shall we do with createlang? Presumably it should start
emitting CREATE EXTENSION not CREATE LANGUAGE, at which point it's
really a general purpose extension installer not a PL installer.
To what extent should we reflect that repurposing in the documentation?
I think changing the name would be going too far: it would break
existing scripts for little return. But it might seem a little weird
to read "createlang -- install an extension" in the table of contents.
Thoughts?
regards, tom lane
On Fri, Mar 4, 2011 at 10:43 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes: >> Tom Lane <tgl@sss.pgh.pa.us> writes: >>> In the simplest form we could implement this by just removing the >>> superuser() check in CREATE EXTENSION. But then people who tried >>> to load a superuser-only extension would get a permissions failure >>> on some random command within the extension, which might be thought >>> less than user-friendly. Also it might be good to have a more >>> explicit marking of superuser-only extensions. So I'm thinking it >>> might be best to invent a control file property along the lines of >>> >>> superuser = false -- default is true >>> >>> which would presently do nothing except control whether to make a >>> superuser() permissions check before running the script. (In future >>> it might do more, but only after a lot of careful thought.) > >> Well it's easy to read that the other way round. Is superuser = true >> means that I need to be a superuser or does it mean that the script will >> get run as superuser no matter what? Not a huge problem, but still. >> What about using the PL terminology here, and calling the property >> 'trusted' (default false, so you have to be a superuser to load them)? > > Hmm. I see your point, but "trusted" seems like it could just as easily > be misunderstood. Anybody have any other opinions about the color of > that bikeshed? I like superuser better than trusted. Or maybe superuser_only. >> In summary, +1 for this proposal. > > I will be working on this today. > >> Also, do we want pg_upgrade to automatically do the create extension >> from unpackaged for us when upgrading a PL? I think it makes sense. > > That seems like a bit of a wart, but if it can be done in not too ugly a > way it's fine with me. I'll leave hacking pg_upgrade to somebody else > though. > > I've thought of two other issues that need some discussion before we > can get very far with this: > > 1. What should pg_dump do with the preinstalled extension plpgsql? > We could put in a hardwired hack to not dump it, on the assumption that > it will be preinstalled in the destination database, but that seems a > bit ugly. When we decided to preinstall the language, we made pg_dump > emit CREATE OR REPLACE LANGUAGE so that the dump script would not fail > if the language was preinstalled. We don't have an equivalent command > for extensions, though. We can either invent one, or put a kluge into > pg_dump. Although I'm on record as generally disliking CREATE IF NOT > EXISTS, I think that having pg_dump emit "CREATE EXTENSION IF NOT EXISTS > foo" might be the best solution here. The reason why is that unlike the > case with other sorts of objects, you typically want the latest version > of an extension installed, not the one that was present in the source > database; so the dump script shouldn't be trying to force a particular > version to be installed, which is the semantics I'd expect of CREATE OR > REPLACE EXTENSION. This is a going to make it hard to restore a 9.0 dump into a 9.1 database, isn't it? > 2. What shall we do with createlang? Presumably it should start > emitting CREATE EXTENSION not CREATE LANGUAGE, at which point it's > really a general purpose extension installer not a PL installer. > To what extent should we reflect that repurposing in the documentation? > I think changing the name would be going too far: it would break > existing scripts for little return. But it might seem a little weird > to read "createlang -- install an extension" in the table of contents. > Thoughts? Maybe we should just get rid of it. It's not really adding any value that I can see. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Mar 4, 2011 at 10:43 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I've thought of two other issues that need some discussion before we
>> can get very far with this:
>>
>> 1. What should pg_dump do with the preinstalled extension plpgsql?
>> We could put in a hardwired hack to not dump it, on the assumption that
>> it will be preinstalled in the destination database, but that seems a
>> bit ugly. When we decided to preinstall the language, we made pg_dump
>> emit CREATE OR REPLACE LANGUAGE so that the dump script would not fail
>> if the language was preinstalled. We don't have an equivalent command
>> for extensions, though. We can either invent one, or put a kluge into
>> pg_dump. Although I'm on record as generally disliking CREATE IF NOT
>> EXISTS, I think that having pg_dump emit "CREATE EXTENSION IF NOT EXISTS
>> foo" might be the best solution here. The reason why is that unlike the
>> case with other sorts of objects, you typically want the latest version
>> of an extension installed, not the one that was present in the source
>> database; so the dump script shouldn't be trying to force a particular
>> version to be installed, which is the semantics I'd expect of CREATE OR
>> REPLACE EXTENSION.
> This is a going to make it hard to restore a 9.0 dump into a 9.1
> database, isn't it?
Not really. The 9.0 dump will contain "CREATE OR REPLACE LANGUAGE
plpgsql", which will do nothing because it's already installed, same
as before.
>> 2. What shall we do with createlang? Presumably it should start
>> emitting CREATE EXTENSION not CREATE LANGUAGE, at which point it's
>> really a general purpose extension installer not a PL installer.
>> To what extent should we reflect that repurposing in the documentation?
>> I think changing the name would be going too far: it would break
>> existing scripts for little return. But it might seem a little weird
>> to read "createlang -- install an extension" in the table of contents.
>> Thoughts?
> Maybe we should just get rid of it. It's not really adding any value
> that I can see.
Hmm. Personally I do use createdb/dropdb but never createlang/droplang;
but I'm well aware that my usage may not be typical. I'm a bit hesitant
to just go and drop these without any warning. I could see deprecating
them for a release or two and then dropping them ... but that doesn't
solve the problem of what to do with them in 9.1.
regards, tom lane
On ons, 2011-03-02 at 13:15 -0800, David E. Wheeler wrote: > If not, how should one require a PL? Come to think of it, how might I > require other features that might not be included in a particular > build, like xpath()? Probably not within the extension mechanism. An RPM package cannot, for example, require kernel features either, even though that is occasionally an actual requirement of some package. Moreover, declaring such a dependency wouldn't actually help making the dependency available, because you cannot just install the dependency, you need to rebuild the (OS/DBMS) kernel.
On Fri, Mar 4, 2011 at 11:19 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Fri, Mar 4, 2011 at 10:43 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> I've thought of two other issues that need some discussion before we >>> can get very far with this: >>> >>> 1. What should pg_dump do with the preinstalled extension plpgsql? >>> We could put in a hardwired hack to not dump it, on the assumption that >>> it will be preinstalled in the destination database, but that seems a >>> bit ugly. When we decided to preinstall the language, we made pg_dump >>> emit CREATE OR REPLACE LANGUAGE so that the dump script would not fail >>> if the language was preinstalled. We don't have an equivalent command >>> for extensions, though. We can either invent one, or put a kluge into >>> pg_dump. Although I'm on record as generally disliking CREATE IF NOT >>> EXISTS, I think that having pg_dump emit "CREATE EXTENSION IF NOT EXISTS >>> foo" might be the best solution here. The reason why is that unlike the >>> case with other sorts of objects, you typically want the latest version >>> of an extension installed, not the one that was present in the source >>> database; so the dump script shouldn't be trying to force a particular >>> version to be installed, which is the semantics I'd expect of CREATE OR >>> REPLACE EXTENSION. > >> This is a going to make it hard to restore a 9.0 dump into a 9.1 >> database, isn't it? > > Not really. The 9.0 dump will contain "CREATE OR REPLACE LANGUAGE > plpgsql", which will do nothing because it's already installed, same > as before. OK. Assuming that'll still be the case even when a 9.1 pg_dump is used on a 9.0 database, that seems OK. >>> 2. What shall we do with createlang? Presumably it should start >>> emitting CREATE EXTENSION not CREATE LANGUAGE, at which point it's >>> really a general purpose extension installer not a PL installer. >>> To what extent should we reflect that repurposing in the documentation? >>> I think changing the name would be going too far: it would break >>> existing scripts for little return. But it might seem a little weird >>> to read "createlang -- install an extension" in the table of contents. >>> Thoughts? > >> Maybe we should just get rid of it. It's not really adding any value >> that I can see. > > Hmm. Personally I do use createdb/dropdb but never createlang/droplang; > but I'm well aware that my usage may not be typical. I'm a bit hesitant > to just go and drop these without any warning. I could see deprecating > them for a release or two and then dropping them ... but that doesn't > solve the problem of what to do with them in 9.1. Well, if we're not going remove them altogether, then my vote would be to leave them unchanged (i.e. they'll still emit CREATE LANGUAGE) and stick a big deprecation warning on them. It isn't necessary to have every SQL command available as a standalone executable. AFAICT, createdb and dropdb are useful primarily because they do the necessary dance of connecting to some other database in order to operate on a different database; and vacuumdb is useful because you can make it process all databases in a loop. Those things can be done with psql too, but it's a bit more complicated. However, neither argument applies to createlang/droplang. Installing and removing extensions and languages is also presumably a pretty infrequent operation, which is another reason to think that we probably don't need a separate tool for it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Mar 4, 2011, at 7:43 AM, Tom Lane wrote: >> Well it's easy to read that the other way round. Is superuser = true >> means that I need to be a superuser or does it mean that the script will >> get run as superuser no matter what? Not a huge problem, but still. >> What about using the PL terminology here, and calling the property >> 'trusted' (default false, so you have to be a superuser to load them)? > > Hmm. I see your point, but "trusted" seems like it could just as easily > be misunderstood. Anybody have any other opinions about the color of > that bikeshed? The trusted/untrusted differentiation confuses me every single time I try to remember which is which. So how about requires_superuseror install_as_superuser? > 1. What should pg_dump do with the preinstalled extension plpgsql? > We could put in a hardwired hack to not dump it, on the assumption that > it will be preinstalled in the destination database, but that seems a > bit ugly. When we decided to preinstall the language, we made pg_dump > emit CREATE OR REPLACE LANGUAGE so that the dump script would not fail > if the language was preinstalled. We don't have an equivalent command > for extensions, though. We can either invent one, or put a kluge into > pg_dump. Although I'm on record as generally disliking CREATE IF NOT > EXISTS, I think that having pg_dump emit "CREATE EXTENSION IF NOT EXISTS > foo" might be the best solution here. The reason why is that unlike the > case with other sorts of objects, you typically want the latest version > of an extension installed, not the one that was present in the source > database; so the dump script shouldn't be trying to force a particular > version to be installed, which is the semantics I'd expect of CREATE OR > REPLACE EXTENSION. +1 to CREATE OR REPLACE EXTENSION. > 2. What shall we do with createlang? Presumably it should start > emitting CREATE EXTENSION not CREATE LANGUAGE, at which point it's > really a general purpose extension installer not a PL installer. > To what extent should we reflect that repurposing in the documentation? > I think changing the name would be going too far: it would break > existing scripts for little return. But it might seem a little weird > to read "createlang -- install an extension" in the table of contents. > Thoughts? ISTM that at this late stage nothing about it should change except the command it issues to the database. I'm all for addinga createext command or something, and deprecating createlang, but I suspect it's a bit late in the dev cycle for 9.1. Best, David
On Mar 4, 2011, at 8:19 AM, Tom Lane wrote: > Hmm. Personally I do use createdb/dropdb but never createlang/droplang; > but I'm well aware that my usage may not be typical. I'm a bit hesitant > to just go and drop these without any warning. I could see deprecating > them for a release or two and then dropping them ... but that doesn't > solve the problem of what to do with them in 9.1. +1 for deprecating them in 9.2. I've found createlang annoying in that it supports only core PLs. Best, David
"David E. Wheeler" <david@kineticode.com> writes:
> On Mar 4, 2011, at 8:19 AM, Tom Lane wrote:
>> Hmm. Personally I do use createdb/dropdb but never createlang/droplang;
>> but I'm well aware that my usage may not be typical. I'm a bit hesitant
>> to just go and drop these without any warning. I could see deprecating
>> them for a release or two and then dropping them ... but that doesn't
>> solve the problem of what to do with them in 9.1.
> +1 for deprecating them in 9.2. I've found createlang annoying in that it supports only core PLs.
Well, the interesting point here is that if these scripts start issuing
CREATE/DROP EXTENSION, they'd work just fine on non-core PLs, assuming
the PL authors get with the program and provide extension packaging.
The only difference between core and non-core PLs will be that the
latter require superuser permission to install, where the former require
only database owner (at least in the trusted variant).
regards, tom lane
Tom Lane <tgl@sss.pgh.pa.us> writes: > Hmm. I see your point, but "trusted" seems like it could just as easily > be misunderstood. Anybody have any other opinions about the color of > that bikeshed? Well it's just that it exists with a comparable meaning elsewhere. > I will be working on this today. Excellent, thanks! > 1. What should pg_dump do with the preinstalled extension plpgsql? [... CREATE EXTENSION IF NOT EXISTS ...] +1 > 2. What shall we do with createlang? Presumably it should start > emitting CREATE EXTENSION not CREATE LANGUAGE, at which point it's > really a general purpose extension installer not a PL installer. My take here would be to rename it to better show its purpose, and continue distributing createlang as symlink to createext. > To what extent should we reflect that repurposing in the documentation? > I think changing the name would be going too far: it would break > existing scripts for little return. But it might seem a little weird > to read "createlang -- install an extension" in the table of contents. > Thoughts? Well with the rename idea, the createext page would say that it used to be called createlang and the createlang page would only exist in the reference, pointing to the createext page. Maybe someday we'll drop it all together but I'm not sure to see the point. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
"David E. Wheeler" <david@kineticode.com> writes:
> On Mar 4, 2011, at 7:43 AM, Tom Lane wrote:
>> Dimitri Fontaine <dimitri@2ndQuadrant.fr> wrote:
>>> What about using the PL terminology here, and calling the property
>>> 'trusted' (default false, so you have to be a superuser to load them)?
>> Hmm. I see your point, but "trusted" seems like it could just as easily
>> be misunderstood. Anybody have any other opinions about the color of
>> that bikeshed?
> The trusted/untrusted differentiation confuses me every single time I try to remember which is which. So how about
requires_superuseror install_as_superuser?
I think install_as_superuser might be read to mean "we will run the
script as superuser, whether the calling user is or not". Which in
fact is a facility that might exist someday, making the chance of
confusion even greater.
requires_superuser isn't bad, but I think I'd rather avoid "requires"
here since we're also using that terminology for prerequisite
extensions. How about "must_be_superuser"?
regards, tom lane
Tom Lane <tgl@sss.pgh.pa.us> writes: > requires_superuser isn't bad, but I think I'd rather avoid "requires" > here since we're also using that terminology for prerequisite > extensions. How about "must_be_superuser"? Sorry to continue painting in old fashioned colors, but if we're not going to reuse established terms from our “glossary”, then I'd better see us using just "superuser" here. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> requires_superuser isn't bad, but I think I'd rather avoid "requires"
>> here since we're also using that terminology for prerequisite
>> extensions. How about "must_be_superuser"?
> Sorry to continue painting in old fashioned colors, but if we're not
> going to reuse established terms from our “glossary”, then I'd better
> see us using just "superuser" here.
[ shrug... ] No objection here. Going once, going twice ...
regards, tom lane
Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Mar 4, 2011 at 11:19 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Hmm. Personally I do use createdb/dropdb but never createlang/droplang;
>> but I'm well aware that my usage may not be typical. I'm a bit hesitant
>> to just go and drop these without any warning. I could see deprecating
>> them for a release or two and then dropping them ... but that doesn't
>> solve the problem of what to do with them in 9.1.
> Well, if we're not going remove them altogether, then my vote would be
> to leave them unchanged (i.e. they'll still emit CREATE LANGUAGE) and
> stick a big deprecation warning on them. It isn't necessary to have
> every SQL command available as a standalone executable.
On reflection I think it makes no sense at all to leave those tools
issuing CREATE/DROP LANGUAGE. We want to move people over to managing
languages via extensions, and leaving those tools unchanged will not
serve that goal. However, I don't mind labeling them as deprecated
and not troubling to point out that they could be used for installing
non-PL extensions.
regards, tom lane
On Mar 5, 2011, at 10:03 AM, Tom Lane wrote: > On reflection I think it makes no sense at all to leave those tools > issuing CREATE/DROP LANGUAGE. We want to move people over to managing > languages via extensions, and leaving those tools unchanged will not > serve that goal. However, I don't mind labeling them as deprecated > and not troubling to point out that they could be used for installing > non-PL extensions. +1 I think this is the sane thing to do in the short run. It remains to be seen whether a createext type tool is even necessary. David