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 mi
Robert Haas writes:
> On Fri, Mar 4, 2011 at 11: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
Dimitri Fontaine writes:
> Tom Lane 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
Tom Lane 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 te
"David E. Wheeler" writes:
> On Mar 4, 2011, at 7:43 AM, Tom Lane wrote:
>> Dimitri Fontaine 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 lik
Tom Lane 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, t
"David E. Wheeler" 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 deprecatin
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 an
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 termin
On Fri, Mar 4, 2011 at 11:19 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Mar 4, 2011 at 10:43 AM, Tom Lane 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 pl
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
exa
Robert Haas writes:
> On Fri, Mar 4, 2011 at 10:43 AM, Tom Lane 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 i
On Fri, Mar 4, 2011 at 10:43 AM, Tom Lane wrote:
> Dimitri Fontaine writes:
>> Tom Lane 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 permissio
Dimitri Fontaine writes:
> Tom Lane 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 extensio
Hi,
Tom Lane 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
Robert Haas writes:
> On Thu, Mar 3, 2011 at 4:31 PM, Tom Lane 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
On Thu, Mar 3, 2011 at 4:31 PM, Tom Lane 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
"David E. Wheeler" 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
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 insta
"David E. Wheeler" 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 includ
Tom Lane 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
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 par
Dimitri Fontaine writes:
> Tom Lane 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
Dimitri Fontaine writes:
> Tom Lane 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
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
"David E. Wheeler" 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 i
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 entirel
"David E. Wheeler" 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
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
> c
"David E. Wheeler" 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
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 o
On Thu, Mar 3, 2011 at 1:30 PM, David E. Wheeler 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 th
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, perha
On Thu, Mar 3, 2011 at 12:56 PM, David E. Wheeler 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, like libxml suppo
On Mar 3, 2011, at 10:12 AM, Dimitri Fontaine wrote:
> "David E. Wheeler" 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 w
"David E. Wheeler" 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 Pos
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 b
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_l
Heikki Linnakangas 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 \
Tom Lane 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 lang
On Thu, Mar 3, 2011 at 4:30 PM, Robert Haas 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 w
On Thu, Mar 3, 2011 at 11:39 AM, Aidan Van Dyk 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 lan
On 03.03.2011 18:30, Robert Haas wrote:
On Thu, Mar 3, 2011 at 11:19 AM, Tom Lane wrote:
Robert Haas 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 Thu, Mar 3, 2011 at 11:19 AM, Tom Lane wrote:
> Robert Haas 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
Tom Lane 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, r
Robert Haas 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
[ 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.
On Thu, Mar 3, 2011 at 10:31 AM, Tom Lane 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 t
Dimitri Fontaine writes:
> Tom Lane 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
Tom Lane 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
Dimitri Fontaine writes:
> Tom Lane 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 co
Tom Lane 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 requirem
On Mar 2, 2011, at 11:00 PM, Tom Lane wrote:
> "David E. Wheeler" 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,
"David E. Wheeler" 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 that it won't happ
It's about dependences.
If my extension requires a procedural language, will adding that language to
the `requires` control key do what I think it should 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 in a particular b
55 matches
Mail list logo
