* 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 the
Stephen Frost sfr...@snowman.net 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
On Dec 2, 2013, at 6:14 AM, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Whether you're targetting a file system template or a catalog template,
PGXN is not a complete solution, you still need to build the extension.
This is true today, but only because PostgreSQL provides the infrastructure
On Mon, Dec 2, 2013 at 10:13 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Heikki Linnakangas hlinnakan...@vmware.com 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.
On Sun, 2013-12-01 at 22:34 -0500, Stephen Frost 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.
I meant extension
On Mon, Dec 2, 2013 at 6:30 PM, Robert Haas robertmh...@gmail.com wrote:
OK, I'll bite. I've been trying to stay out of this thread, but I
really *don't* understand what this patch is about. Extensions, as
they exist today, are installed from the filesystem and their contents
are not dumped.
On Mon, Dec 2, 2013 at 2:33 PM, Greg Stark st...@mit.edu wrote:
On Mon, Dec 2, 2013 at 6:30 PM, Robert Haas robertmh...@gmail.com wrote:
OK, I'll bite. I've been trying to stay out of this thread, but I
really *don't* understand what this patch is about. Extensions, as
they exist today, are
Greg Stark st...@mit.edu writes:
On Mon, Dec 2, 2013 at 6:30 PM, Robert Haas robertmh...@gmail.com wrote:
OK, I'll bite. I've been trying to stay out of this thread, but I
really *don't* understand what this patch is about. Extensions, as
Thanks!
they exist today, are installed from the
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
Stephen Frost sfr...@snowman.net 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
David,
* David E. Wheeler (da...@justatheory.com) wrote:
On Dec 2, 2013, at 6:14 AM, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Whether you're targetting a file system template or a catalog template,
PGXN is not a complete solution, you still need to build the extension.
This is
Stephen Frost sfr...@snowman.net writes:
* David E. Wheeler (da...@justatheory.com) wrote:
This is true today, but only because PostgreSQL provides the
infrastructure for building and installing extensions that entails `make
make install`. If Postgres provided some other method of building
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
Problem solved! The only downside is that the use of this facility
would have to be restricted to superusers, but the current consensus
on this thread is that we should restrict *this* facility to
superusers also, so we're not really
Stephen Frost sfr...@snowman.net writes:
What I've been trying to point out is that there's absolutely zero need
for the 'extension template' part of this to make a pg_restore work for
an entirely-in-the-catalog extension. I realize that's how you've done
it with this patch set but that
* Jeff Davis (pg...@j-davis.com) wrote:
On Sun, 2013-12-01 at 22:34 -0500, Stephen Frost 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
On Mon, Dec 2, 2013 at 3:02 PM, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Greg Stark st...@mit.edu writes:
On Mon, Dec 2, 2013 at 6:30 PM, Robert Haas robertmh...@gmail.com wrote:
OK, I'll bite. I've been trying to stay out of this thread, but I
really *don't* understand what this patch
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
Stephen Frost sfr...@snowman.net writes:
What I've been trying to point out is that there's absolutely zero need
for the 'extension template' part of this to make a pg_restore work for
an entirely-in-the-catalog extension. I realize that's
On Mon, Dec 2, 2013 at 3:17 PM, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Stephen Frost sfr...@snowman.net writes:
What I've been trying to point out is that there's absolutely zero need
for the 'extension template' part of this to make a pg_restore work for
an entirely-in-the-catalog
* Robert Haas (robertmh...@gmail.com) wrote:
Speaking only for myself, I think the thing I most disliked about that
proposal was the syntax. I'd rather see each extension member dumped
separately, and then later dump the extension itself as CREATE
EXTENSION ... WITH NO CONTENTS or similar
Robert Haas robertmh...@gmail.com writes:
Speaking only for myself, I think the thing I most disliked about that
proposal was the syntax. I'd rather see each extension member dumped
separately, and then later dump the extension itself as CREATE
EXTENSION ... WITH NO CONTENTS or similar
Stephen Frost sfr...@snowman.net writes:
I'm not convinced we really need to solve that problem, but one way to
solve it 'cleanly' would be to seperate the two types of extensions,
perhaps by calling them by different names or inventing a namespace for
extensions.
My understanding is that
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
Stephen Frost sfr...@snowman.net writes:
I'm not convinced we really need to solve that problem, but one way to
solve it 'cleanly' would be to seperate the two types of extensions,
perhaps by calling them by different names or inventing a
On 3 December 2013 02:02, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Stephen Frost sfr...@snowman.net 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
Tom Dunstan pg...@tomd.cc writes:
On 3 December 2013 02:02, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Stephen Frost sfr...@snowman.net 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
On 3 December 2013 12:12, Tom Lane t...@sss.pgh.pa.us wrote:
Problem? It's not a bug that you get hstore 1.2 when you dump from 9.2
and reload into 9.3; that's a feature. You wanted an upgrade, presumably,
or you'd not have been going to 9.3 in the first place. The entire reason
why the
On Sun, 2013-12-01 at 15:48 +0100, Dimitri Fontaine wrote:
Jeff Davis pg...@j-davis.com 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
On Mon, 2013-12-02 at 11:07 +0200, Heikki Linnakangas wrote:
On 12/02/2013 05:34 AM, Stephen Frost wrote:
2. When 9.4 gets released, we need some solid advice for extension
authors. If they have a native shared library, I assume we just tell
them to keep using the file-based templates.
Jeff Davis pg...@j-davis.com 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
Jeff Davis pg...@j-davis.com 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
On Sun, 2013-12-01 at 15:58 +0100, Dimitri Fontaine wrote:
Jeff Davis pg...@j-davis.com 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
* 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, but
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
Stephen Frost sfr...@snowman.net 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
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 for
* 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
On Wed, 2013-11-27 at 18:34 +0100, Dimitri Fontaine wrote:
Stephen Frost sfr...@snowman.net 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'
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:
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 EXTENSION
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:
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
Jeff Davis pg...@j-davis.com 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
Jeff Davis pg...@j-davis.com 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
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 pg...@j-davis.com 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
Stephen Frost sfr...@snowman.net 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.
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
EXTENSION
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 full
On Sat, 2013-11-30 at 23:03 +0100, Dimitri Fontaine wrote:
Jeff Davis pg...@j-davis.com 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.
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
Hi,
Heikki Linnakangas hlinnakan...@vmware.com 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
Dimitri Fontaine dimi...@2ndquadrant.fr 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
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Dimitri Fontaine dimi...@2ndquadrant.fr 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
Tom Lane t...@sss.pgh.pa.us 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,
--
Stephen Frost sfr...@snowman.net 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.
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.
On 24.11.2013 00:19, Dimitri Fontaine wrote:
Jeff Davis pg...@j-davis.com 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
* 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..
I
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. not native
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
Hi,
Jeff Davis pg...@j-davis.com 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
Dimitri Fontaine wrote:
Stephen Frost sfr...@snowman.net 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
Stephen Frost sfr...@snowman.net 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
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
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:
Peter Eisentraut pete...@gmx.net 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
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 included
On Tue, Sep 3, 2013 at 4:20 AM, David Fetter da...@fetter.org 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
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Alvaro Herrera alvhe...@2ndquadrant.com 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
Peter Eisentraut pete...@gmx.net 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
Dimitri Fontaine wrote:
Peter Eisentraut pete...@gmx.net 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
Alvaro Herrera alvhe...@2ndquadrant.com 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
Hi,
Boszormenyi Zoltan z...@cybertec.at 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
2013-08-27 18:09 keltezéssel, Dimitri Fontaine írta:
Hi,
Boszormenyi Zoltan z...@cybertec.at 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
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
Hi,
2013-08-04 15:20 keltezéssel, Dimitri Fontaine írta:
Thom Brown t...@linux.com 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
Thom Brown t...@linux.com 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
On 1 August 2013 18:01, Dimitri Fontaine dimi...@2ndquadrant.fr 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
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 description of the patch in a style that
targets the detailed commit
101 - 176 of 176 matches
Mail list logo
