Robert Haas writes:
> Considering that this constitutes a major redesign and that the
> updated patch hasn't been posted over a month later, it seems past
> time to mark this Returned with Feedback. So I've done that.
I was hoping to be able to code that while the CF is running but
obviously tha
On Thu, Jan 26, 2012 at 12:40 PM, Dimitri Fontaine
wrote:
> So I'm going to prepare the next version of the patch with this design:
Considering that this constitutes a major redesign and that the
updated patch hasn't been posted over a month later, it seems past
time to mark this Returned with Fe
Le 28 janvier 2012 21:46, David E. Wheeler a écrit :
> On Jan 27, 2012, at 2:19 AM, Cédric Villemain wrote:
>
>>> Also --exclude-extension?
>>
>> It might be the default.
>> We need something to dump the content of
>> pg_catalog.pg_extension_script (or whatever table is going to contain
>> SQL cod
On Jan 27, 2012, at 2:19 AM, Cédric Villemain wrote:
>> Also --exclude-extension?
>
> It might be the default.
> We need something to dump the content of
> pg_catalog.pg_extension_script (or whatever table is going to contain
> SQL code), per extension or all.
I think dim said --no-extensions wo
>> So I'm going to prepare the next version of the patch with this design:
>>
>> - in catalog extension scripts for inline extension
>>
>> pg_extension_script(extoid, oldversion, version, script)
>>
>> oldversion is null when create extension is used
>> unless when using the create extension
On Thu, Jan 26, 2012 at 3:48 PM, David E. Wheeler wrote:
> On Jan 26, 2012, at 9:40 AM, Dimitri Fontaine wrote:
>
>> Not for 9.2, but I can't help thinking that if we could manage to host
>> the .so module itself in the catalogs, we could solve updating it in a
>> transactional way and more import
On Jan 26, 2012, at 9:40 AM, Dimitri Fontaine wrote:
> So I'm going to prepare the next version of the patch with this design:
>
> - in catalog extension scripts for inline extension
>
> pg_extension_script(extoid, oldversion, version, script)
>
> oldversion is null when create extension is
Robert Haas writes:
> On Mon, Jan 23, 2012 at 7:59 PM, Daniel Farina wrote:
>> Things are still a bit ugly in the more complex cases: consider
>> PostGIS's linkage against libproj and other libraries. In order to
After thinking about that for a while I think we should not include the
shared mod
On Mon, Jan 23, 2012 at 7:59 PM, Daniel Farina wrote:
> Things are still a bit ugly in the more complex cases: consider
> PostGIS's linkage against libproj and other libraries. In order to
> cover all cases, I feel that what I need is an optional hook (for the
> same of argument, let's say it's a
On Mon, Jan 23, 2012 at 8:17 AM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>>> Ok, but then, what about .so files? Wouldn't it make sense to be able
>>> to ship also the executable modules needed, and if not, why not?
>
> Now you can dump/restore any extension fully, and we can even ship any
Robert Haas writes:
>> Ok, but then, what about .so files? Wouldn't it make sense to be able
>> to ship also the executable modules needed, and if not, why not?
>
> Sure, that would be as useful as any other part of this feature. We'd
> have to think carefully about how to make it secure, though
On Mon, Jan 23, 2012 at 10:46 AM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>> Hmm, I don't think I like that design. I think we should view this as
>> a way to embed the SQL and control files needed by the extension in
>> the server, rather than a separate thing called an inline extension.
Robert Haas writes:
> Hmm, I don't think I like that design. I think we should view this as
> a way to embed the SQL and control files needed by the extension in
> the server, rather than a separate thing called an inline extension.
> If pg_dump is going to dump those files, it ought to dump them
On Mon, Jan 23, 2012 at 10:26 AM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>> Hmm. But CREATE EXTENSION / ALTER EXTENSION doesn't seem right,
>> because the files in the directory correspond to *available*
>> extensions, not already-created ones. We need some way of dumping and
>
> I would
Robert Haas writes:
> Hmm. But CREATE EXTENSION / ALTER EXTENSION doesn't seem right,
> because the files in the directory correspond to *available*
> extensions, not already-created ones. We need some way of dumping and
I would have limited the dump query to only known installed extensions,
ri
On Mon, Jan 23, 2012 at 10:04 AM, Dimitri Fontaine
wrote:
> And then basebackup and pg_upgrade would just work, and for dump and
> restore we still need to find something not violating the POLA.
>
> I think that would mean offering a backend function that list all files
> from a given extension an
Robert Haas writes:
> I am pretty concerned that we find a design that does not involve
> pg_dump needing to dump out the extension contents, though: that seems
> to me to be missing the point of having extensions in the first place.
I was just trying to explain where I'm coming from, I'm not wed
On Mon, Jan 23, 2012 at 8:25 AM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>> "virtual directory" - e.g. CREATE TABLE pg_extension_virtualdir
>> (filename text, content text) which would be modifiable by the DBA and
>> would be searched either before or after the filesystem itself. This
>> c
Robert Haas writes:
> "virtual directory" - e.g. CREATE TABLE pg_extension_virtualdir
> (filename text, content text) which would be modifiable by the DBA and
> would be searched either before or after the filesystem itself. This
> catalog wouldn't be dumped by pg_dump, and there would be no chan
On Mon, Jan 23, 2012 at 5:53 AM, Dimitri Fontaine
wrote:
>> Probably the worst issue with that is that in typical installations,
>> the share/extension/ directory would be read-only to the server, and a
>> lot of people might be uncomfortable with making it writable. Not sure
>> whether we should
Le 23 janvier 2012 11:53, Dimitri Fontaine a écrit :
> Tom Lane writes:
>> On reflection it seems like this patch is simply offering the wrong
>> solution for the problem. I agree that it could be useful to install
>> extensions without having direct access to the server's filesystem,
>> but it
Tom Lane writes:
> On reflection it seems like this patch is simply offering the wrong
> solution for the problem. I agree that it could be useful to install
> extensions without having direct access to the server's filesystem,
> but it doesn't seem to follow that we must lobotomize existing exte
> Is it such a bad idea to store the literal text of the extension's
> pieces (control file and corresponding SQL program) in catalogs? I'm
> not sure if I understand why everyone is so interested in a special
> interaction with the file system in some way. By the same token,
> extensions can be
On Sun, Jan 22, 2012 at 8:42 PM, Robert Haas wrote:
> On Sun, Jan 22, 2012 at 3:20 PM, Daniel Farina wrote:
>> A few anecdotes does not constitute evidence, but it does look like
>> some people pay attention to any additional versioning foothold they
>> can get.
>
> Sure, but just because some pe
Robert Haas writes:
> ... If people
> are doing management via "pure FEBE", good for them: but that doesn't
> explain why it shoudn't be done all in userspace, with all of the
> flexibility that gives.
On reflection it seems like this patch is simply offering the wrong
solution for the problem.
On Sun, Jan 22, 2012 at 3:20 PM, Daniel Farina wrote:
> A few anecdotes does not constitute evidence, but it does look like
> some people pay attention to any additional versioning foothold they
> can get.
Sure, but just because some people do it doesn't make it a good idea.
I can personally atte
On Fri, Jan 20, 2012 at 3:33 PM, Daniel Farina wrote:
> On Fri, Jan 20, 2012 at 2:48 PM, Heikki Linnakangas
> wrote:
>> Even if you give the version number in the CREATE EXTENSION command, it's by
>> convention that people actually maintain a sane versioning policy. If people
>> don't take versio
On Fri, Jan 20, 2012 at 2:48 PM, Heikki Linnakangas
wrote:
> Even if you give the version number in the CREATE EXTENSION command, it's by
> convention that people actually maintain a sane versioning policy. If people
> don't take version management seriously, you will quickly end up with five
> di
On 21.01.2012 00:00, Daniel Farina wrote:
I think this is somewhat rube-goldberg-esque, and denies non-superuser
roles the ability to get more version management of schema and
operators. As-is many organizations are submitting "migrations" via
plain SQL that include committing to a version manag
On Thu, Jan 19, 2012 at 8:15 AM, Tom Lane wrote:
>> Heikki Linnakangas writes:
>>> Frankly I don't see the point of this. If the extension is an independent
>>> piece of (SQL) code, developed separately from an application, with its own
>>> lifecycle, a .sql file seems like the best way to distri
Robert Haas writes:
>> Maybe you would want the system to be able to determine the oldest
>> version to start from to reach the current default_version given in the
>> control file, but I guess it would be better to add another property
>> like default_full_version or such (last_stop?).
>
> Possib
On Fri, Jan 20, 2012 at 11:29 AM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>> peeves is that the system doesn't know how to do an install of v1.1 by
>> running the v1.0 script followed by the 1.0-1.1 upgrade script, which
>
> Did you try
>
> CREATE EXTENSION foo FROM 1.0;
Well, yes, that w
Robert Haas writes:
> peeves is that the system doesn't know how to do an install of v1.1 by
> running the v1.0 script followed by the 1.0-1.1 upgrade script, which
Did you try
CREATE EXTENSION foo FROM 1.0;
Maybe you would want the system to be able to determine the oldest
version to start f
On Fri, Jan 20, 2012 at 8:52 AM, Dimitri Fontaine
wrote:
> Tom Lane writes:
>> Robert Haas writes:
>>> I guess the question is: for what purpose?
>>
>> Indeed, it seems like such a thing is not an extension at all anymore,
>> or at least it gives up many of the useful properties of extensions.
>
Tom Lane writes:
> Robert Haas writes:
>> I guess the question is: for what purpose?
>
> Indeed, it seems like such a thing is not an extension at all anymore,
> or at least it gives up many of the useful properties of extensions.
I'm thinking that a common name and version number tracked in the
Robert Haas writes:
> On Thu, Jan 19, 2012 at 3:42 PM, Dimitri Fontaine
>> I'm trying to open the extension facilities (versions being the first of
>> them, think \dx) to application PL code, and to hosted environments
>> where you're not granted access to the server's file system.
> I guess the
On Thu, Jan 19, 2012 at 3:42 PM, Dimitri Fontaine
wrote:
> Tom Lane writes:
>> I'm with Heikki on not believing that this is a good idea. If you are
>> trying to do careful versioning of a set of object definitions, you want
>> to stick the things in a file, you don't want them just flying by in
Tom Lane writes:
> I'm with Heikki on not believing that this is a good idea. If you are
> trying to do careful versioning of a set of object definitions, you want
> to stick the things in a file, you don't want them just flying by in
> submitted SQL.
I'm trying to open the extension facilities
On Jan 19, 2012, at 7:21 AM, Dimitri Fontaine wrote:
> Now, for the dependency on a SQL file hosting the content, it's easier
> to just connect to the databases and get them the script in the SQL
> command rather than deploying a set of files: that means OS level
> packaging, either RPM or debian
Dimitri Fontaine writes:
> Heikki Linnakangas writes:
>> Frankly I don't see the point of this. If the extension is an independent
>> piece of (SQL) code, developed separately from an application, with its own
>> lifecycle, a .sql file seems like the best way to distribute it. If it's
>> not, ie.
Heikki Linnakangas writes:
> Frankly I don't see the point of this. If the extension is an independent
> piece of (SQL) code, developed separately from an application, with its own
> lifecycle, a .sql file seems like the best way to distribute it. If it's
> not, ie. if it's an integral part of the
On 08.01.2012 22:36, Dimitri Fontaine wrote:
The extension mechanism we added in 9.1 is aimed at allowing a fully
integrated contrib management, which was big enough a goal to preclude
doing anything else in its first release.
Hooray!
Now we have it and we can think some more about what featu
Hi,
The extension mechanism we added in 9.1 is aimed at allowing a fully
integrated contrib management, which was big enough a goal to preclude
doing anything else in its first release.
Now we have it and we can think some more about what features we want
covered, and a pretty obvious one that's
43 matches
Mail list logo
