Dimitri Fontaine writes:
> In the patch we're talking about, the --extension-script is an
> accumulative option that needs an argument, so you do
>pg_dump --extension-script istore --extension-script foo
> or if you're into short options
>pg_dump -X istore -X foo -X bar
My reaction to
Dimitri Fontaine writes:
> Robert Haas writes:
>> Well, there's certainly a point, because IIUC Dimitri's patch dumps
>> the file into the pg_dump output no matter whether the file originally
>> came from an SQL command or the filesystem. IMHO, anyone who thinks
>> that isn't going to break thin
Robert Haas writes:
> In other words, the first paragraph is arguing for something like the
> notion of an extension template - the ability to store the extension
> files inside the server, in cases where you don't want them to appear
> in the file system. But perhaps implemented using functions
Robert Haas writes:
> Well, with the design you have proposed, unless you have access to the
> filesystem, it ain't gonna work. And if you have access to the
> filesystem, then this whole discussion is moot.
I did mention that this version of the patch is only ready to host the
current design ta
On Wed, Dec 5, 2012 at 5:43 PM, Dimitri Fontaine wrote:
>> I don't find that argument convincing in the slightest. Could I perhaps
>> convince you to dig up a reference? I would be interested in the
>> arguments for that design back then.
>
> I think here it is:
>
> http://archives.postgresql.or
On Wed, Dec 5, 2012 at 5:08 PM, Dimitri Fontaine wrote:
> Robert Haas writes:
>> Yeah, DROP will work. But what about ALTER .. UPDATE?
>
> What about it?
Well, with the design you have proposed, unless you have access to the
filesystem, it ain't gonna work. And if you have access to the
filesy
Andres Freund writes:
>> The argument here is that the user would then have packaged its
>> extension as files in the meantime. If not, that's operational error. A
>> backup you didn't restore successfully isn't a backup anyway.
>
> Uh. Wait. What? If that argument is valid, we don't need anything
On 2012-12-05 23:28:45 +0100, Dimitri Fontaine wrote:
> Alvaro Herrera writes:
> > What happens on a normal pg_dump of the complete database? For
> > extensions that were installed using strings instead of files, do I get
> > a string back? Because if not, the restore is clearly going to fail
>
Alvaro Herrera writes:
> What happens on a normal pg_dump of the complete database? For
> extensions that were installed using strings instead of files, do I get
> a string back? Because if not, the restore is clearly going to fail
> anyway.
The argument here is that the user would then have pa
Dimitri Fontaine escribió:
> Robert Haas writes:
> > Well, there's certainly a point, because IIUC Dimitri's patch dumps
> > the file into the pg_dump output no matter whether the file originally
> > came from an SQL command or the filesystem. IMHO, anyone who thinks
> > that isn't going to brea
Robert Haas writes:
> Yeah, DROP will work. But what about ALTER .. UPDATE?
What about it?
> Well, there's certainly a point, because IIUC Dimitri's patch dumps
> the file into the pg_dump output no matter whether the file originally
> came from an SQL command or the filesystem. IMHO, anyone w
On Wed, Dec 5, 2012 at 2:54 PM, Alvaro Herrera wrote:
> Robert Haas escribió:
>> I have no objection whatsoever to the concept of storing the SQL and
>> control files somewhere that doesn't need access to the server
>> filesystem - in fact, I think I previously proposed allowing those to
>> be sto
On 2012-12-05 16:42:38 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2012-12-05 16:20:41 -0500, Tom Lane wrote:
> >> GUC or no GUC, it'd still be letting an unprivileged network-exposed
> >> application (PG) do something that's against any sane system-level
> >> security policy. Lipstick
Andres Freund writes:
> On 2012-12-05 16:20:41 -0500, Tom Lane wrote:
>> GUC or no GUC, it'd still be letting an unprivileged network-exposed
>> application (PG) do something that's against any sane system-level
>> security policy. Lipstick is not gonna help this pig.
> What about the non-writab
On 2012-12-05 16:20:41 -0500, Tom Lane wrote:
> Dimitri Fontaine writes:
> >> On 2012-12-05 13:18:16 -0500, Tom Lane wrote:
> >>> I think you're wasting your time to imagine that that case will ever be
> >>> "fixed". Allowing the server to scribble on executable files would set
> >>> off all kind
Dimitri Fontaine writes:
>> On 2012-12-05 13:18:16 -0500, Tom Lane wrote:
>>> I think you're wasting your time to imagine that that case will ever be
>>> "fixed". Allowing the server to scribble on executable files would set
>>> off all kinds of security alarm bells, and rightly so. If Postgres
Andres Freund writes:
> On 2012-12-05 21:16:52 +0100, Dimitri Fontaine wrote:
>> Now if we can't fix the executable files situation, what about making
>> the C coded extensions not require an executable anymore? I'm thinking
>> about studying what it would take exactly to write a PL/C where the
>>
Alvaro Herrera writes:
> +1. Certainly a pg_dump patch's thread is not the place to propose it.
Sure. Sorry about that, the goal of that previous message was to let
people come to understand better my whole vision of what is an
Extension, a contrib, and where we are what I wanted us to build.
I
Andres Freund escribió:
> On 2012-12-05 21:16:52 +0100, Dimitri Fontaine wrote:
> > Now if we can't fix the executable files situation, what about making
> > the C coded extensions not require an executable anymore? I'm thinking
> > about studying what it would take exactly to write a PL/C where t
So,
Lots of things are being said, most of them are really interesting and
some of them are just re-hashing what we said about a year ago in the
"Inline Extensions" thread, whose conclusion was that the key not to
have two different beasts (inline, file based) was for pg_dump to
process them all t
On 2012-12-05 21:16:52 +0100, Dimitri Fontaine wrote:
> Andres Freund writes:
> > Adding some *NON WRITABLE* per-cluster library directory doesn't seem to
> > be as controversion as other suggestions.
>
> Well, it means a per-initdb (user driven) location where to store binary
> files, ask Tom wha
Andres Freund writes:
> Maybe I am missing something, but you already can separate them per
> major version. You co-wrote the debian infrastructure to do so for some
> debian packages, so I am not sure what you mean here.
The debian infrastructure I've help building is all about compiling an
exte
Robert Haas escribió:
> I have no objection whatsoever to the concept of storing the SQL and
> control files somewhere that doesn't need access to the server
> filesystem - in fact, I think I previously proposed allowing those to
> be stored in a database table. You could do that with something l
On Wed, Dec 5, 2012 at 2:19 PM, Andres Freund wrote:
>> IIUC, under this proposal, the client would instead need to execute
>> some SQL code that looks something this (I'm faking the syntax here,
>> forgive me, but the patch doesn't seem to contemplate ALTER):
>>
>> ALTER EXTENSION myextension UPD
On 2012-12-05 14:10:34 -0500, Robert Haas wrote:
> On Wed, Dec 5, 2012 at 2:01 PM, Andres Freund wrote:
> > E.g. for years I had a set of (trigger) functions to counted the number
> > of rows in a table in a lockless manner. That's used in 10+ applications
> > of former clients of mine. All (plpg)
On Wed, Dec 5, 2012 at 2:01 PM, Andres Freund wrote:
> E.g. for years I had a set of (trigger) functions to counted the number
> of rows in a table in a lockless manner. That's used in 10+ applications
> of former clients of mine. All (plpg)sql.
> Imagine I want to ship an updated version that 1.
On 2012-12-05 13:50:27 -0500, Robert Haas wrote:
> On Wed, Dec 5, 2012 at 12:47 PM, Andres Freund wrote:
> > For me it seems pretty natural to support dumping extension the way they
> > got created. I.e. a plain CREATE EXTENSION ...; if the extension was
> > preinstalled and some form that include
On Wed, Dec 5, 2012 at 12:47 PM, Andres Freund wrote:
> For me it seems pretty natural to support dumping extension the way they
> got created. I.e. a plain CREATE EXTENSION ...; if the extension was
> preinstalled and some form that includes the extension source if you
> installed it via the conn
On Wed, Dec 5, 2012 at 5:22 AM, Dimitri Fontaine wrote:
> This patch is all about enabling users to create extension without
> having to ship them as root on the file system of the database(s)
> server(s) first.
Right, but it changes the way that existing extensions *dump*, which
seems to me to u
On 2012-12-05 13:18:16 -0500, Tom Lane wrote:
> Dimitri Fontaine writes:
> > At the SQL level, extensions do live in a database. The only reason why
> > we currently have them on the file system is binary executables (.so,
> > .dylib, .dll). And those are not per database, not even per cluster, no
On 2012-12-05 20:23:29 +0200, Heikki Linnakangas wrote:
> On 05.12.2012 20:13, Andres Freund wrote:
> >But I really really would like them to go to a per-database directory
> >not a per-cluster one. Otherwise the coordination between different
> >database "owners" inside a cluster will get really h
On 2012-12-05 20:15:42 +0200, Heikki Linnakangas wrote:
> On 05.12.2012 20:07, Tom Lane wrote:
> >Heikki Linnakangas writes:
> >>And whether extension control files (or the same information stored in a
> >>table or wherever) should be per-database or per cluster - that's *yet*
> >>another separate
On 05.12.2012 20:13, Andres Freund wrote:
But I really really would like them to go to a per-database directory
not a per-cluster one. Otherwise the coordination between different
database "owners" inside a cluster will get really hairy. I want to be
able to install different versions of an appli
Dimitri Fontaine writes:
> At the SQL level, extensions do live in a database. The only reason why
> we currently have them on the file system is binary executables (.so,
> .dylib, .dll). And those are not per database, not even per cluster, not
> even per major version, they are *per server*. It'
On 05.12.2012 20:07, Tom Lane wrote:
Heikki Linnakangas writes:
And whether extension control files (or the same information stored in a
table or wherever) should be per-database or per cluster - that's *yet*
another separate issue. You could argue for either behavior.
I think anyone arguing
On 2012-12-05 12:55:42 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2012-12-05 19:13:10 +0200, Heikki Linnakangas wrote:
> >> And I still don't understand why pg_dump needs to know about any of this...
>
> > Extensions should be fully per-database and we want pg_dump backups to
> > be res
Heikki Linnakangas writes:
> And whether extension control files (or the same information stored in a
> table or wherever) should be per-database or per cluster - that's *yet*
> another separate issue. You could argue for either behavior.
I think anyone arguing for the former is confusing an in
Andres Freund writes:
> On 2012-12-05 19:13:10 +0200, Heikki Linnakangas wrote:
>> And I still don't understand why pg_dump needs to know about any of this...
> Extensions should be fully per-database and we want pg_dump backups to
> be restorable into another database/clusters/servers.
Wait a m
Heikki Linnakangas writes:
> Ok - but that it yet another issue, not to be confused with how you deploy
> extensions. If we are to have such a mode in pg_dump, it should be able to
> dump *all* extensions, regardless of how they were deployed. (ok, might be
> difficult for extensions that include
On 2012-12-05 19:40:58 +0200, Heikki Linnakangas wrote:
> On 05.12.2012 19:27, Andres Freund wrote:
> >>And I still don't understand why pg_dump needs to know about any of this...
> >
> >Extensions should be fully per-database and we want pg_dump backups to
> >be restorable into another database/cl
On 05.12.2012 19:27, Andres Freund wrote:
And I still don't understand why pg_dump needs to know about any of this...
Extensions should be fully per-database and we want pg_dump backups to
be restorable into another database/clusters/servers. So having a mode
for pg_dump that actually makes dum
On 2012-12-05 19:13:10 +0200, Heikki Linnakangas wrote:
> On 05.12.2012 12:22, Dimitri Fontaine wrote:
> >Heikki Linnakangas writes:
> >>No doubt about that. I'm sure extensions written in pure SQL or PL/pgSQL are
> >>very common. But what does that have to do with this patch?
> >
> >This patch is
On 05.12.2012 12:22, Dimitri Fontaine wrote:
Heikki Linnakangas writes:
No doubt about that. I'm sure extensions written in pure SQL or PL/pgSQL are
very common. But what does that have to do with this patch?
This patch is all about enabling users to create extension without
having to ship th
Heikki Linnakangas writes:
> No doubt about that. I'm sure extensions written in pure SQL or PL/pgSQL are
> very common. But what does that have to do with this patch?
This patch is all about enabling users to create extension without
having to ship them as root on the file system of the database
On 20.11.2012 21:25, Simon Riggs wrote:
On 19 November 2012 16:25, Robert Haas wrote:
Beyond that, I think much of the appeal of the extension feature is
that it dumps as "CREATE EXTENSION hstore;" and nothing more. That
allows you to migrate a dump between systems with different but
compatib
On 19 November 2012 16:25, Robert Haas wrote:
> Beyond that, I think much of the appeal of the extension feature is
> that it dumps as "CREATE EXTENSION hstore;" and nothing more. That
> allows you to migrate a dump between systems with different but
> compatible versions of the hstore and have
Robert Haas writes:
> I'm not opposed to the idea of being able to make extensions without
> files on disk work ... but I consider it a niche use case; the
> behavior we have right now works well for me and hopefully for others
> most of the time.
Apparently I'm not the only one doing extensions
Robert Haas writes:
> That approach seems likely to break things for the hoped-for parallel
> pg_dump feature, though I'm not sure exactly in what way.
Will the parallel dump solve the dependencies and extension membership
properties in parallel too?
> Beyond that, I think much of the appeal of
On Thu, Nov 15, 2012 at 3:09 PM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>>> Please find attached to this email an RFC patch implementing the basics
>>> of the pg_dump --extension-script option. After much discussion around
>>> the concept of an inline extension, we decided last year that a
Robert Haas writes:
>> Please find attached to this email an RFC patch implementing the basics
>> of the pg_dump --extension-script option. After much discussion around
>> the concept of an inline extension, we decided last year that a good
>> first step would be pg_dump support for an extension's
On Mon, Nov 12, 2012 at 11:00 AM, Dimitri Fontaine
wrote:
> Please find attached to this email an RFC patch implementing the basics
> of the pg_dump --extension-script option. After much discussion around
> the concept of an inline extension, we decided last year that a good
> first step would be
51 matches
Mail list logo
