Robert Haas robertmh...@gmail.com writes:
On Fri, Mar 4, 2011 at 11:19 AM, Tom Lane t...@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
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
Hi,
Tom Lane t...@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
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Tom Lane t...@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
On Fri, Mar 4, 2011 at 10:43 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Tom Lane t...@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
Robert Haas robertmh...@gmail.com writes:
On Fri, Mar 4, 2011 at 10:43 AM, Tom Lane t...@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
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
On Fri, Mar 4, 2011 at 11:19 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Mar 4, 2011 at 10:43 AM, Tom Lane t...@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
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
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
David E. Wheeler da...@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
Tom Lane t...@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.
David E. Wheeler da...@kineticode.com writes:
On Mar 4, 2011, at 7:43 AM, Tom Lane wrote:
Dimitri Fontaine dimi...@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
Tom Lane t...@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
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Tom Lane t...@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
Tom Lane t...@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
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Tom Lane t...@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,
Tom Lane t...@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.
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Tom Lane t...@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
On Thu, Mar 3, 2011 at 10:31 AM, Tom Lane t...@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
[ 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.)
Robert Haas robertmh...@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
Tom Lane t...@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
On Thu, Mar 3, 2011 at 11:19 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@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
On 03.03.2011 18:30, Robert Haas wrote:
On Thu, Mar 3, 2011 at 11:19 AM, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haasrobertmh...@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
On Thu, Mar 3, 2011 at 11:39 AM, Aidan Van Dyk ai...@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
On Thu, Mar 3, 2011 at 4:30 PM, Robert Haas robertmh...@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
Tom Lane t...@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
Heikki Linnakangas heikki.linnakan...@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
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
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
David E. Wheeler da...@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
On Mar 3, 2011, at 10:12 AM, Dimitri Fontaine wrote:
David E. Wheeler da...@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
On Thu, Mar 3, 2011 at 12:56 PM, David E. Wheeler da...@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,
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
On Thu, Mar 3, 2011 at 1:30 PM, David E. Wheeler da...@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,
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
David E. Wheeler da...@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
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
David E. Wheeler da...@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
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 version number. No other syntax at all.
It can be added later.
I basically agree with Robert that requires = 9.1 is entirely
David E. Wheeler da...@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
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
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Tom Lane t...@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
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Tom Lane t...@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
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
Tom Lane t...@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
David E. Wheeler da...@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
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
David E. Wheeler da...@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
On Thu, Mar 3, 2011 at 4:31 PM, Tom Lane t...@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
Robert Haas robertmh...@gmail.com writes:
On Thu, Mar 3, 2011 at 4:31 PM, Tom Lane t...@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,
David E. Wheeler da...@kineticode.com writes:
If my extension requires a procedural language, will adding that language to
the `requires` control key do what I think it should do?
No.
Probably in future the standard PLs will be packaged as extensions, and
then it will work. The main reason
On Mar 2, 2011, at 11:00 PM, Tom Lane wrote:
David E. Wheeler da...@kineticode.com writes:
If my extension requires a procedural language, will adding that language to
the `requires` control key do what I think it should do?
No.
Probably in future the standard PLs will be packaged as
54 matches
Mail list logo
