Stephen Frost writes:
> I don't like the idea of having a pg_dump/restore mechanism that
> intentionally tries to go out and install the latest version of whatever
> extension was installed in the old DB by downloading it from PGXN,
> building it, and then installing it... Is that what people are
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
> So when you pg_dump | pg_restore from 9.1 into 9.3, if pg_dump were to
> be nitpicky about the version of hstore with the command
>
> CREATE EXTENSION hstore VERSION '1.0';
>
> What would happen is that pg_restore would fail.
>
> That's just
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
> Tom Lane writes:
> > Yes, exactly. What's more, you're going to face huge push-back from
> > vendors who are concerned about security (which is most of them).
>
> Last time I talked with vendors, they were working in the Open Shift
> team at R
Stephen Frost writes:
> On the other hand, I can appreciate the concern that we don't really
> want a dump/restore to include the extension definition when it's
> already on the filesystem. That said, it amazes me that we don't
> include the version # of the extension in pg_dump's 'CREATE EXTENSI
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
> Stephen Frost writes:
> > Fine- so we need a step that goes from 'source' to 'built'. I don't see
> > that step being done in or by a PG backend process. Adding a new option
> > which can take a pgxn source and build a script from it which can
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
> Stephen Frost writes:
> > Clearly we need the information from the extension package (the scripts
> > which are on the PG server's filesystem today, but need not be in the
> > future) but that doesn't mean we need to keep those text blobs in the
Tom Lane writes:
> Stephen Frost writes:
>> * Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
>>> Then as soon as we are able to CREATE EXTENSION mystuff; without ever
>>> pre-installing files on the file system as root, then we would like to
>>> be able to do just that even with binary modules.
Stephen Frost writes:
> * Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
>> Then as soon as we are able to CREATE EXTENSION mystuff; without ever
>> pre-installing files on the file system as root, then we would like to
>> be able to do just that even with binary modules.
> I really just don't
Heikki Linnakangas writes:
> I fear we're wandering off the point again. So let me repeat: It must be
> possible to install the same extension the way you do today, and using the
> new mechanism.
The way you do today is running make install or apt-get install or
something else to write files in t
Stephen Frost writes:
> Fine- so we need a step that goes from 'source' to 'built'. I don't see
> that step being done in or by a PG backend process. Adding a new option
> which can take a pgxn source and build a script from it which can be run
> against PG via libpq is what I'd be going for- bu
Stephen Frost writes:
> Clearly we need the information from the extension package (the scripts
> which are on the PG server's filesystem today, but need not be in the
> future) but that doesn't mean we need to keep those text blobs in the
> catalog.
So, I guess it would have been good to hear ab
On 12/02/2013 04:14 PM, Dimitri Fontaine wrote:
Stephen Frost writes:
What is the next step to allow an extension pulled down from pgxn to be
installed, unchanged, into a given database?
An extension packaging system.
Unchanged is not a goal, and not possible even today.
PGXN is a *source b
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
> Stephen Frost writes:
> > What is the next step to allow an extension pulled down from pgxn to be
> > installed, unchanged, into a given database?
>
> An extension packaging system.
>
> Unchanged is not a goal, and not possible even today.
I'
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
> Stephen Frost writes:
> > *That doesn't make this approach the right one*. If anything, I'm
> > afraid we've ended up building ourselves a rube goldberg machine because
> > of this constant struggle to fit a square peg into a round hole.
>
> T
Stephen Frost writes:
> What is the next step to allow an extension pulled down from pgxn to be
> installed, unchanged, into a given database?
An extension packaging system.
Unchanged is not a goal, and not possible even today.
PGXN is a *source based* packaging system. You can't just install w
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
> > There should be no difference between file-based extensions and
> > catalog-based extensions. It's just two different ways to install the same
> > extension. The extension author doesn't need to care about that, it's the
> > DBA that decides wh
* Heikki Linnakangas (hlinnakan...@vmware.com) wrote:
> Right. I think Jeff was thinking of a catalog representation for
> extensions that haven't been installed yet, but are available in the
> system and could be installed with CREATE EXTENSION foo.
I really don't particularly see value in this u
Stephen Frost writes:
>> > Having a versioning notion (and whatever other meta data we, or an
>> > extension author, feels is useful) for what are otherwise simple containers
>> > (aka the schematic we already have..) makes sense and it would be great to
>> > provide support around that, but not t
Heikki Linnakangas writes:
> Right. I think Jeff was thinking of a catalog representation for extensions
> that haven't been installed yet, but are available in the system and could
> be installed with CREATE EXTENSION foo. I wouldn't mind having a catalog
> like that. Even without any of this ext
On 2013-12-02 11:07:28 +0200, Heikki Linnakangas wrote:
> >Perhaps I'm missing something- but we already *have* a catalog
> >representation for every extension that's ever installed into a given
> >database. A representation that's a heck of a lot better than a big
> >text blob.
>
> Right. I thin
On 12/02/2013 05:34 AM, Stephen Frost wrote:
* Jeff Davis (pg...@j-davis.com) wrote:
I see where you're coming from, but after some thought, and looking at
the patch, I think we really do want a catalog representation for (at
least some) extensions.
Perhaps I'm missing something- but we alread
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
> # Why do we want extensions to manage PL user code?
Having a management system for sets of objects is a *great* idea- and
one which we already have through schemas. What we don't have is any
kind of versioning system built-in or other metadata
Jeff,
* Jeff Davis (pg...@j-davis.com) wrote:
> I see where you're coming from, but after some thought, and looking at
> the patch, I think we really do want a catalog representation for (at
> least some) extensions.
Perhaps I'm missing something- but we already *have* a catalog
representation fo
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
> Stephen Frost writes:
> > Without that, all of the information about a given extension is already in
> > the database in our dependency system. As you pointed out, there was
>
> That's not entirely true. We would still be missing some informati
* Jeff Davis (pg...@j-davis.com) wrote:
> To throw another idea out, also based on the premise that it's a
> namespace problem: if a non-superuser creates an extension template,
> then we force a prefix of that user's username. So a superuser can
> create an "base" extension template with no prefix
On Sun, 2013-12-01 at 15:58 +0100, Dimitri Fontaine wrote:
> Jeff Davis writes:
> Either of those solution are fine to me, with or without the automated
> SET ROLE when a superuser is installing an extension from a template
> owned by a non-superuser.
>
> Tell me your preference, I'll work on the
Jeff Davis writes:
>> So maybe we should have “SECURITY DEFINER” and “SECURITY INVOKER”
>> extension templates, the default being “SECURITY DEFINER”?
>
> That doesn't seem to answer Heikki's stated concern, because a malicious
> non-superuser would just declare the trojan extension to be SECURITY
Jeff Davis writes:
> I don't see why we are trying to accommodate a case where the author
> doesn't offer enough full SQL scripts and offers broken downgrade
> scripts; or why that case is different from offering broken upgrade
> scripts.
That's fair enough I guess. I will work on automating the
On Sat, 2013-11-30 at 23:03 +0100, Dimitri Fontaine wrote:
> Jeff Davis writes:
> >> When a superuser CREATE EXTENSION against a template that has been
> >> provided by a non-privileged user, automatically SET ROLE to that user
> >> before doing so, avoiding escalation privileges.
> >
> > Th
On Sat, 2013-11-30 at 22:55 +0100, Dimitri Fontaine wrote:
> So we need the "default_major_version" capabilities, whatever the
> name we choose. Hence my inclusion of that feature in the Extension
> Template patch.
What we need is a means to install versions for which we don't have ful
Dimitri,
On Saturday, November 30, 2013, Dimitri Fontaine wrote:
>
> The current extension model is simple enough to reason about. A script
> must be provided in a template and is executed at CREATE EXTENSION time
> or at ALTER EXTENSION UPDATE time, and pg_dump only contains the CREATE
> EXTENSIO
Stephen Frost writes:
> Without that, all of the information about a given extension is already in
> the database in our dependency system. As you pointed out, there was
That's not entirely true. We would still be missing some information
from the extension control file.
> previously a notion of
Jeff Davis writes:
> 1. During the initial development of extensions, there was discussion
> about ordered version numbers and dependencies on the version (e.g.
> requires foo >= 2.1). Outside the scope of this patch, of course, but is
> that something that we can still do later? Or are we buildin
On Saturday, November 30, 2013, Dimitri Fontaine wrote:
>
> Also consider multi-tenancy installations. Certainly, you don't want any
> database owner to be able to review PL code from any other database
> owner in the same cluster when each database owner is another customer
>
I'm planning to do a
Jeff Davis writes:
>> When a superuser CREATE EXTENSION against a template that has been
>> provided by a non-privileged user, automatically SET ROLE to that user
>> before doing so, avoiding escalation privileges.
>
> That proposal is worded like a special case for superusers, and I don't
>
Jeff Davis writes:
> I think that Stephen was just talking about the naming. I would have
> expected the names to be something like "xtmpl" (which is the shortest
> abbreviation that came to my mind) rather than "tpl", for instance. Use
> of "template" is a bit ambiguous.
To be honest I'm not fol
On Wed, 2013-11-27 at 18:34 +0100, Dimitri Fontaine wrote:
> I merged your patch in, rebased against master, fixed some more typos I
> found, and filled in the gaps you found in the docs. Version 17 of the
> patch is attached to that email, passes `make check`.
A couple more questions:
1. During
On Tue, 2013-11-26 at 01:37 +0200, Heikki Linnakangas wrote:
> I want to be able to download extension.zip from pgxn.org, and then
> install it on a server. I want to be able to install it the traditional
> way, by unzipping it to the filesystem, or via libpq by using this new
> feature.
I see
On Wed, 2013-11-27 at 18:34 +0100, Dimitri Fontaine wrote:
> The other main point that will change the current code is dealing with
> superusers and security concerns. Baring objections, I'm going to
> implement a variation of what I did propose in the thread:
>
> When a superuser CREATE EXTENSI
On Sat, 2013-11-30 at 01:05 -0800, Jeff Davis wrote:
> Unless I'm missing something, I'd be inclined to just get rid of the
> concept of DEFAULT FULL VERSION just to keep the documentation simpler
> without losing any real functionality.
I found some explanation of the original reasoning in these
On Wed, 2013-11-27 at 18:34 +0100, Dimitri Fontaine wrote:
> Stephen Frost writes:
> > We already have other 'template' objects in the system and I'm not
> > excited about the confusion. This also applies to 'CreateTemplate',
> > 'CreateTemplateTupleDesc', right down to 'template.h' and 'template
On 11/26/2013 10:07 PM, Dimitri Fontaine wrote:
> What I now think we should do is only grant superusers the privileges to
> install an extension from a template they own or is owned by another
> superuser.
Say what? Superusers bypass all privileges by definition.
--
Vik
--
Sent via pgsql-h
Stephen Frost writes:
> These wouldn't be PG "extensions" really though, which it seems folks
> are pretty hung up on. There would also be no support for binary or
> untrusted components, which is a bit frustrating, as you'd like to be
> able to support those if you're a superuser. Trying to bui
Tom Lane writes:
> As I've said multiple times before, this is an absolute nonstarter.
FWIW, I was explaining the model that I didn't want to follow.
Thanks for approving, even if that's not a surprise as the model I did
follow is the one we agreed on a year ago.
Regards,
--
Dimitri Fontaine
h
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Dimitri Fontaine writes:
> > So, to support uploading PGXN zip files directly within the backend, now
> > the backend must be in a position to unpack the archive and build the
> > extension, then it must know where the build artefacts are going to be
> > fo
Dimitri Fontaine writes:
> So, to support uploading PGXN zip files directly within the backend, now
> the backend must be in a position to unpack the archive and build the
> extension, then it must know where the build artefacts are going to be
> found or it needs to `make install` in a known pref
Hi,
Heikki Linnakangas writes:
> I still don't like this. What I suggested back in December was to have a
> simple mechanism to upload an extension zip file to the server via libpq
> (http://www.postgresql.org/message-id/50bf80a6.20...@vmware.com). The idea
> developed from that into the concept
On Tue, 2013-11-26 at 01:37 +0200, Heikki Linnakangas wrote:
> Back in December, when I agreed that "upload zip file via libpq" might
> be useful, Tom suggested that we call control+sql file a "template", and
> the installed entity an "extension".
Simply uploading "safe" extension files (i.e. no
* Heikki Linnakangas (hlinnakan...@vmware.com) wrote:
> On 24.11.2013 00:19, Dimitri Fontaine wrote:
> >This patch has received extensive review in July and I think it now
> >properly implements the design proposed by Tom and Heikki in 9.3/CF4.
>
> Ok, since my name has been mentioned, I'll bite..
On 24.11.2013 00:19, Dimitri Fontaine wrote:
Jeff Davis writes:
In the CF app, this is marked "Ready for Committer". That's a bit vague
here, considering Dimitri, you, Peter, and Alvaro are all committers.
Who is this patch waiting on? Is the discussion concluding, or does it
need another round
Dimitri,
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
> As the path didn't make it already, yes it needs another (final) round
> of review. The main difficulty in reviewing is understanding the design
> and the relation in between our current model of extensions and what
> this patch offers.
Hi,
Jeff Davis writes:
> In the CF app, this is marked "Ready for Committer". That's a bit vague
> here, considering Dimitri, you, Peter, and Alvaro are all committers.
> Who is this patch waiting on? Is the discussion concluding, or does it
> need another round of review?
Thanks for the confusi
On Mon, 2013-11-04 at 08:43 -0500, Stephen Frost wrote:
> I'll still go ahead and start looking through this, per our discussion.
In the CF app, this is marked "Ready for Committer". That's a bit vague
here, considering Dimitri, you, Peter, and Alvaro are all committers.
Who is this patch waiting
Dimitri Fontaine wrote:
> Stephen Frost writes:
> > Are there any other changes you have pending for this..? Would be nice
> > to see the latest version which you've tested and which patches cleanly
> > against master... ;)
>
> I just rebased now, please see attached. I had to pick new OIDs in s
Stephen Frost writes:
> Are there any other changes you have pending for this..? Would be nice
> to see the latest version which you've tested and which patches cleanly
> against master... ;)
I just rebased now, please see attached. I had to pick new OIDs in some
places too, but that's about it.
Dimitri,
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
> So please find v15 of the patch attached to this email, that passes all
> previously done checks and this one too now.
Looks like there's been a bit of unfortunate bitrot due to Tom's change
to disable fancy output:
patching file src/
On Tue, Sep 3, 2013 at 4:20 AM, David Fetter wrote:
> On Mon, Sep 02, 2013 at 02:32:16AM -0400, Peter Eisentraut wrote:
>> On Thu, 2013-08-29 at 12:16 +0200, Dimitri Fontaine wrote:
>> > Here's v14 of the patch with pg_upgrade support fixed, so that the
>> > automated setup that Peter built is abl
On Mon, Sep 02, 2013 at 02:32:16AM -0400, Peter Eisentraut wrote:
> On Thu, 2013-08-29 at 12:16 +0200, Dimitri Fontaine wrote:
> > Here's v14 of the patch with pg_upgrade support fixed, so that the
> > automated setup that Peter built is able to have at it!
>
> Fails cpluspluscheck:
>
> In file i
Peter Eisentraut writes:
> Fails cpluspluscheck:
Turns out I'm discovering that particular check, thanks! I could
reproduce and fix the error locally after being led to the command
./src/tools/pginclude/cpluspluscheck.
So please find v15 of the patch attached to this email, that passes all
previ
On Thu, 2013-08-29 at 12:16 +0200, Dimitri Fontaine wrote:
> Here's v14 of the patch with pg_upgrade support fixed, so that the
> automated setup that Peter built is able to have at it!
Fails cpluspluscheck:
In file included from /tmp/cpluspluscheck.5g2uWw/test.cpp:3:0:
./src/include/commands/tem
Dimitri Fontaine writes:
> Alvaro Herrera writes:
>> "make check" in contrib/pg_upgrade should do the trick.
>
> PASSED
>
> Even after I added extension to the serial_schedule. I don't know if I
> need to do anything specific on that area, will wait about some feedback
> on that before sending a
Alvaro Herrera writes:
> "make check" in contrib/pg_upgrade should do the trick.
PASSED
Even after I added extension to the serial_schedule. I don't know if I
need to do anything specific on that area, will wait about some feedback
on that before sending a new version of the patch. Meanwhile my
Dimitri Fontaine wrote:
> Peter Eisentraut writes:
> > make -C pg_upgrade_support all
>
> Do we have something automated to easily test pg_upgrade?
"make check" in contrib/pg_upgrade should do the trick.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7
Peter Eisentraut writes:
> make -C pg_upgrade_support all
Do we have something automated to easily test pg_upgrade?
My memories of how pg_upgrade works with extensions makes me believe
that I don't have anything special to do when those extensions have been
made available through a template: the
This doesn't build:
make -C pg_upgrade_support all
make[2]: Entering directory
`/var/lib/jenkins/jobs/postgresql_commitfest_world/workspace/contrib/pg_upgrade_support'
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute
-Wfo
2013-08-27 18:09 keltezéssel, Dimitri Fontaine írta:
Hi,
Boszormenyi Zoltan writes:
Here's a review for this patch.
Thanks for that review Zoltan!
You're welcome.
I would like to see the control parameters documented in allcaps
in CREATE EXTENSION TEMPLATE. Then ALTER EXTENSION
TEMPLATE s
Hi,
Boszormenyi Zoltan writes:
> Here's a review for this patch.
Thanks for that review Zoltan!
> No, it has one reject in src/bin/pg_dump/pg_backup_archiver.c.
> It was obvious to fix, version 12a is attached.
Included in the new version of the patch (v13), attached.
> It has extended the SQ
Hi,
2013-08-04 15:20 keltezéssel, Dimitri Fontaine írta:
Thom Brown writes:
Could you please resubmit this without using SnapshotNow as it's no longer
supported?
Sure, sorry that I missed that, please find v12 attached.
Here's a review for this patch.
* Is the patch in a patch format which
Thom Brown writes:
> Could you please resubmit this without using SnapshotNow as it's no longer
> supported?
Sure, sorry that I missed that, please find v12 attached.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
templates.v12.patch.gz
De
On 1 August 2013 18:01, Dimitri Fontaine wrote:
> Hi,
>
> Please find attached to this email the latest and greatest version of
> in-line SQL only extensions support, known as "Extension Templates" and
> which could be renamed "In-Catalog Extension Templates".
>
> I've included a high-level descr
101 - 170 of 170 matches
Mail list logo
