Re: [HACKERS] [PATCH] Store Extension Options

2014-03-26 Thread Fabrízio de Royes Mello
On Thu, Mar 13, 2014 at 5:35 PM, Robert Haas robertmh...@gmail.com wrote: Well, I'm not sure that's really any big deal, but I'm not wedded to the label idea. My principal concern is: I'm opposed to allowing unvalidated options into the database. I think it should be a requirement that if

Re: [HACKERS] [PATCH] Store Extension Options

2014-03-13 Thread Stephen Frost
* Tom Lane (t...@sss.pgh.pa.us) wrote: I don't really think partial validation makes sense. We could just remove the whole topic, and tell extension authors that it's up to them to defend themselves against bizarre values stored for their table options. But I'm wondering if there's really so

Re: [HACKERS] [PATCH] Store Extension Options

2014-03-13 Thread Robert Haas
On Thu, Mar 13, 2014 at 12:47 AM, Simon Riggs si...@2ndquadrant.com wrote: On 13 March 2014 02:14, Robert Haas robertmh...@gmail.com wrote: I'm not sure why this is being blocked. This is a community contribution that seeks to improve everybody's options. Blocking it does *nothing* to prevent

Re: [HACKERS] [PATCH] Store Extension Options

2014-03-13 Thread Andres Freund
On 2014-03-13 09:17:36 -0400, Robert Haas wrote: It is very true that there are other ways for extensions to manage per-table options. You previously said that, but I really don't see any. Which way out there exists that a) doesn't leave garbage after the relation is dropped or renamed b) is

Re: [HACKERS] [PATCH] Store Extension Options

2014-03-13 Thread Robert Haas
On Thu, Mar 13, 2014 at 9:26 AM, Andres Freund and...@2ndquadrant.com wrote: On 2014-03-13 09:17:36 -0400, Robert Haas wrote: It is very true that there are other ways for extensions to manage per-table options. You previously said that, but I really don't see any. Which way out there exists

Re: [HACKERS] [PATCH] Store Extension Options

2014-03-13 Thread Andres Freund
On 2014-03-13 10:03:03 -0400, Robert Haas wrote: On Thu, Mar 13, 2014 at 9:26 AM, Andres Freund and...@2ndquadrant.com wrote: On 2014-03-13 09:17:36 -0400, Robert Haas wrote: It is very true that there are other ways for extensions to manage per-table options. You previously said that,

Re: [HACKERS] [PATCH] Store Extension Options

2014-03-13 Thread Simon Riggs
On 13 March 2014 13:17, Robert Haas robertmh...@gmail.com wrote: The bottom line here is that, as in previous years, there are a certain number of people who show up near the end of CF4 and are unhappy that some patch didn't get committed. Generally, they allege that (1) there's nothing

Re: [HACKERS] [PATCH] Store Extension Options

2014-03-13 Thread Tom Lane
[ forgot to respond to this part ] Andres Freund and...@2ndquadrant.com writes: They currently don't seem to create invalidations on the objects they are set upon, maybe we should change that? No, because relcache doesn't store security labels to start with. There's a separate catalog cache

Re: [HACKERS] [PATCH] Store Extension Options

2014-03-13 Thread Andres Freund
On 2014-03-13 10:24:09 -0400, Tom Lane wrote: Andres Freund and...@2ndquadrant.com writes: But security labels are a nice idea, will think about it. AFAICs there's no builtin subdivision within the label for one provider which is a bit of a shame but solvable. The biggest issue I see is

Re: [HACKERS] [PATCH] Store Extension Options

2014-03-13 Thread Robert Haas
On Thu, Mar 13, 2014 at 10:20 AM, Andres Freund and...@2ndquadrant.com wrote: Well, I'm not going to claim that the methods that exist today are perfect. Things you can do include: (1) the table of tables approach, (2) abusing comments, and perhaps (3) abusing the security label machinery.

Re: [HACKERS] [PATCH] Store Extension Options

2014-03-13 Thread Simon Riggs
On 13 March 2014 13:17, Stephen Frost sfr...@snowman.net wrote: In the end, perhaps we should just add another field which is called 'custom_reloptions' and allow that to be the wild west? That makes sense. ... and allow that to be the wild west? but that would be an emotive phrase that

Re: [HACKERS] [PATCH] Store Extension Options

2014-03-13 Thread Tom Lane
Andres Freund and...@2ndquadrant.com writes: But security labels are a nice idea, will think about it. AFAICs there's no builtin subdivision within the label for one provider which is a bit of a shame but solvable. The biggest issue I see is that it essentially seems to require that the

Re: [HACKERS] [PATCH] Store Extension Options

2014-03-13 Thread Simon Riggs
On 13 March 2014 14:03, Robert Haas robertmh...@gmail.com wrote: On Thu, Mar 13, 2014 at 9:26 AM, Andres Freund and...@2ndquadrant.com wrote: On 2014-03-13 09:17:36 -0400, Robert Haas wrote: It is very true that there are other ways for extensions to manage per-table options. You previously

Re: [HACKERS] [PATCH] Store Extension Options

2014-03-13 Thread Robert Haas
On Thu, Mar 13, 2014 at 10:22 AM, Simon Riggs si...@2ndquadrant.com wrote: On 13 March 2014 13:17, Robert Haas robertmh...@gmail.com wrote: The bottom line here is that, as in previous years, there are a certain number of people who show up near the end of CF4 and are unhappy that some patch

Re: [HACKERS] [PATCH] Store Extension Options

2014-03-13 Thread Alvaro Herrera
Robert Haas escribió: Basically, my feeling is that if you install an extension that adds new table-level options, that's effectively a new version of the database, and expecting a dump from that version to restore into a vanilla database is about as reasonable as expecting 9.4 dumps to

Re: [HACKERS] [PATCH] Store Extension Options

2014-03-13 Thread Andres Freund
On 2014-03-13 10:26:11 -0400, Tom Lane wrote: [ forgot to respond to this part ] Andres Freund and...@2ndquadrant.com writes: They currently don't seem to create invalidations on the objects they are set upon, maybe we should change that? No, because relcache doesn't store security

Re: [HACKERS] [PATCH] Store Extension Options

2014-03-13 Thread Simon Riggs
On 13 March 2014 14:36, Simon Riggs si...@2ndquadrant.com wrote: I like that suggestion, all of it. Perhaps change it to METADATA LABEL ? Damn. It works, apart from the fact that we don't get parameter=value. That may not be critical, since most use cases I can think of are booleans. --

Re: [HACKERS] [PATCH] Store Extension Options

2014-03-13 Thread Andres Freund
On 2014-03-13 10:31:12 -0400, Robert Haas wrote: I think the really interesting question here is how the dump-and-reload issue ought to be handled. As Tom says, it seems on the surface as though you can either require that the provider be loaded for that, or you can accept unvalidated

Re: [HACKERS] [PATCH] Store Extension Options

2014-03-13 Thread Tom Lane
Andres Freund and...@2ndquadrant.com writes: On 2014-03-13 10:26:11 -0400, Tom Lane wrote: No, because relcache doesn't store security labels to start with. There's a separate catalog cache for security labels, I believe, and invalidating entries in that ought to be sufficient. There doesn't

Re: [HACKERS] [PATCH] Store Extension Options

2014-03-13 Thread Robert Haas
On Thu, Mar 13, 2014 at 10:27 AM, Andres Freund and...@2ndquadrant.com wrote: On 2014-03-13 10:24:09 -0400, Tom Lane wrote: Andres Freund and...@2ndquadrant.com writes: But security labels are a nice idea, will think about it. AFAICs there's no builtin subdivision within the label for one

Re: [HACKERS] [PATCH] Store Extension Options

2014-03-13 Thread Robert Haas
On Thu, Mar 13, 2014 at 10:45 AM, Andres Freund and...@2ndquadrant.com wrote: On 2014-03-13 10:31:12 -0400, Robert Haas wrote: I think the really interesting question here is how the dump-and-reload issue ought to be handled. As Tom says, it seems on the surface as though you can either

Re: [HACKERS] [PATCH] Store Extension Options

2014-03-13 Thread Andres Freund
On 2014-03-13 11:11:51 -0400, Tom Lane wrote: Andres Freund and...@2ndquadrant.com writes: On 2014-03-13 10:26:11 -0400, Tom Lane wrote: No, because relcache doesn't store security labels to start with. There's a separate catalog cache for security labels, I believe, and invalidating

Re: [HACKERS] [PATCH] Store Extension Options

2014-03-13 Thread Alvaro Herrera
Robert Haas escribió: Well, I don't have a big problem with the idea that some sessions might not have a certain extension loaded. For some extensions, that might not lead to very coherent behavior, but I guess it's the extension developer's job to tell the user whether or not that

Re: [HACKERS] [PATCH] Store Extension Options

2014-03-13 Thread Robert Haas
On Thu, Mar 13, 2014 at 11:11 AM, Tom Lane t...@sss.pgh.pa.us wrote: Andres Freund and...@2ndquadrant.com writes: On 2014-03-13 10:26:11 -0400, Tom Lane wrote: No, because relcache doesn't store security labels to start with. There's a separate catalog cache for security labels, I believe,

Re: [HACKERS] [PATCH] Store Extension Options

2014-03-13 Thread Andres Freund
On 2014-03-13 11:15:56 -0400, Robert Haas wrote: On Thu, Mar 13, 2014 at 10:27 AM, Andres Freund and...@2ndquadrant.com wrote: On 2014-03-13 10:24:09 -0400, Tom Lane wrote: Andres Freund and...@2ndquadrant.com writes: But security labels are a nice idea, will think about it. AFAICs

Re: [HACKERS] [PATCH] Store Extension Options

2014-03-13 Thread Andres Freund
On 2014-03-13 11:20:02 -0400, Robert Haas wrote: At the same time, I don't feel compelled to provide an autoload mechanism to cover the case where a user tries to set a label in a session which does not have the label provider preloaded. I don't think there's that much need for that to be

Re: [HACKERS] [PATCH] Store Extension Options

2014-03-13 Thread Andres Freund
On 2014-03-13 11:26:10 -0400, Robert Haas wrote: On Thu, Mar 13, 2014 at 11:11 AM, Tom Lane t...@sss.pgh.pa.us wrote: If there's not a catcache for pg_seclabels, I'd have no objection to adding one. As for your userland cache objection, you certainly could build such a thing using the

Re: [HACKERS] [PATCH] Store Extension Options

2014-03-13 Thread Tom Lane
Andres Freund and...@2ndquadrant.com writes: On 2014-03-13 11:26:10 -0400, Robert Haas wrote: I have however had the thought before that it would be nice to allow for callbacks of invalidation functions of some kind even on catalogs that don't have catcaches. Unfortunately the format

Re: [HACKERS] [PATCH] Store Extension Options

2014-03-13 Thread Robert Haas
On Thu, Mar 13, 2014 at 12:11 PM, Tom Lane t...@sss.pgh.pa.us wrote: Andres Freund and...@2ndquadrant.com writes: On 2014-03-13 11:26:10 -0400, Robert Haas wrote: I have however had the thought before that it would be nice to allow for callbacks of invalidation functions of some kind even on

Re: [HACKERS] [PATCH] Store Extension Options

2014-03-13 Thread Robert Haas
On Thu, Mar 13, 2014 at 11:42 AM, Andres Freund and...@2ndquadrant.com wrote: On 2014-03-13 11:26:10 -0400, Robert Haas wrote: On Thu, Mar 13, 2014 at 11:11 AM, Tom Lane t...@sss.pgh.pa.us wrote: If there's not a catcache for pg_seclabels, I'd have no objection to adding one. As for your

Re: [HACKERS] [PATCH] Store Extension Options

2014-03-13 Thread Robert Haas
On Thu, Mar 13, 2014 at 11:37 AM, Andres Freund and...@2ndquadrant.com wrote: I seriously doubt that's going to work nicely. Now you've implicitly introduced a dependency from every object that has a label to the label provider. pg_dump is going to have to restore the validator function

Re: [HACKERS] [PATCH] Store Extension Options

2014-03-13 Thread Robert Haas
On Thu, Mar 13, 2014 at 11:30 AM, Alvaro Herrera alvhe...@2ndquadrant.com wrote: Robert Haas escribió: Well, I don't have a big problem with the idea that some sessions might not have a certain extension loaded. For some extensions, that might not lead to very coherent behavior, but I guess

Re: [HACKERS] [PATCH] Store Extension Options

2014-03-12 Thread Fabrízio de Royes Mello
On Tue, Mar 11, 2014 at 8:42 PM, Simon Riggs si...@2ndquadrant.com wrote: On 11 March 2014 18:33, Tom Lane t...@sss.pgh.pa.us wrote: Simon Riggs si...@2ndquadrant.com writes: -1 to *requiring* validation for table-level options for exactly the same reasons we no longer validate custom

Re: [HACKERS] [PATCH] Store Extension Options

2014-03-12 Thread Robert Haas
On Mon, Mar 10, 2014 at 9:33 PM, Alvaro Herrera alvhe...@2ndquadrant.com wrote: I haven't touched pg_dump yet, but if this proposed design sits well with everyone, my intention is that the dump output will contain the pg_register_option_namespace() calls necessary so that a table definition

Re: [HACKERS] [PATCH] Store Extension Options

2014-03-12 Thread Josh Berkus
On 03/12/2014 03:58 PM, Robert Haas wrote: I don't like the idea of using reloptions to let people attach arbitrary unvalidated settings to tables. I consider the way things work with GUCs to be a bug, not a feature, and definitely not something I want to propagate into every other area of

Re: [HACKERS] [PATCH] Store Extension Options

2014-03-12 Thread Alvaro Herrera
Josh Berkus escribió: On 03/12/2014 03:58 PM, Robert Haas wrote: I don't like the idea of using reloptions to let people attach arbitrary unvalidated settings to tables. I consider the way things work with GUCs to be a bug, not a feature, and definitely not something I want to propagate

Re: [HACKERS] [PATCH] Store Extension Options

2014-03-12 Thread Simon Riggs
On 12 March 2014 22:58, Robert Haas robertmh...@gmail.com wrote: I don't like the idea of using reloptions to let people attach arbitrary unvalidated settings to tables. I respect your opinion. If you disagree, don't use them. Same as is possible for RULEs etc. I consider the way things

Re: [HACKERS] [PATCH] Store Extension Options

2014-03-12 Thread Robert Haas
On Wed, Mar 12, 2014 at 9:38 PM, Simon Riggs si...@2ndquadrant.com wrote: On 12 March 2014 22:58, Robert Haas robertmh...@gmail.com wrote: I don't like the idea of using reloptions to let people attach arbitrary unvalidated settings to tables. I respect your opinion. If you disagree, don't

Re: [HACKERS] [PATCH] Store Extension Options

2014-03-12 Thread Simon Riggs
On 13 March 2014 02:14, Robert Haas robertmh...@gmail.com wrote: I'm not sure why this is being blocked. This is a community contribution that seeks to improve everybody's options. Blocking it does *nothing* to prevent individual extensions from providing table-level options - we give them

Re: [HACKERS] [PATCH] Store Extension Options

2014-03-11 Thread Alvaro Herrera
Tom Lane escribió: =?ISO-8859-1?Q?Fabr=EDzio_de_Royes_Mello?= fabriziome...@gmail.com writes: You are correct. pg_dump export reloptions using WITH clause of CREATE TABLE statement. I.e.: CREATE TABLE foo ( ) WITH (autovacuum_enabled=false, bdr.do_replicate=false); So if this

Re: [HACKERS] [PATCH] Store Extension Options

2014-03-11 Thread Simon Riggs
On 11 March 2014 17:26, Alvaro Herrera alvhe...@2ndquadrant.com wrote: Tom Lane escribió: =?ISO-8859-1?Q?Fabr=EDzio_de_Royes_Mello?= fabriziome...@gmail.com writes: You are correct. pg_dump export reloptions using WITH clause of CREATE TABLE statement. I.e.: CREATE TABLE foo ( ) WITH

Re: [HACKERS] [PATCH] Store Extension Options

2014-03-11 Thread Fabrízio de Royes Mello
On Tue, Mar 11, 2014 at 2:43 PM, Simon Riggs si...@2ndquadrant.com wrote: On 11 March 2014 17:26, Alvaro Herrera alvhe...@2ndquadrant.com wrote: Tom Lane escribió: =?ISO-8859-1?Q?Fabr=EDzio_de_Royes_Mello?= fabriziome...@gmail.com writes: You are correct. pg_dump export reloptions using

Re: [HACKERS] [PATCH] Store Extension Options

2014-03-11 Thread Tom Lane
Simon Riggs si...@2ndquadrant.com writes: -1 to *requiring* validation for table-level options for exactly the same reasons we no longer validate custom GUCs. Well, that is an interesting analogy, but I'm not sure how much it applies here. In the case of a GUC, you can fairly easily validate

Re: [HACKERS] [PATCH] Store Extension Options

2014-03-11 Thread Simon Riggs
On 11 March 2014 18:33, Tom Lane t...@sss.pgh.pa.us wrote: Simon Riggs si...@2ndquadrant.com writes: -1 to *requiring* validation for table-level options for exactly the same reasons we no longer validate custom GUCs. Well, that is an interesting analogy, but I'm not sure how much it applies

Re: [HACKERS] [PATCH] Store Extension Options

2014-03-10 Thread Alvaro Herrera
Fabrízio de Royes Mello escribió: On Fri, Mar 7, 2014 at 5:56 PM, Alvaro Herrera alvhe...@2ndquadrant.comwrote: I am reworking this patch, both to accomodate earlier review comments and to fix the multiple verify step of namespaces, as noted by Tom in 4530.1390023...@sss.pgh.pa.us

Re: [HACKERS] [PATCH] Store Extension Options

2014-03-07 Thread Alvaro Herrera
I am reworking this patch, both to accomodate earlier review comments and to fix the multiple verify step of namespaces, as noted by Tom in 4530.1390023...@sss.pgh.pa.us -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services --

Re: [HACKERS] [PATCH] Store Extension Options

2014-03-07 Thread Fabrízio de Royes Mello
On Fri, Mar 7, 2014 at 5:56 PM, Alvaro Herrera alvhe...@2ndquadrant.comwrote: I am reworking this patch, both to accomodate earlier review comments and to fix the multiple verify step of namespaces, as noted by Tom in 4530.1390023...@sss.pgh.pa.us This link is broken... -- Fabrízio de

Re: [HACKERS] [PATCH] Store Extension Options

2014-03-07 Thread Fabrízio de Royes Mello
On Fri, Mar 7, 2014 at 7:21 PM, Andres Freund and...@2ndquadrant.comwrote: On 2014-03-07 19:14:48 -0300, Fabrízio de Royes Mello wrote: On Fri, Mar 7, 2014 at 5:56 PM, Alvaro Herrera alvhe...@2ndquadrant.com wrote: I am reworking this patch, both to accomodate earlier review comments

Re: [HACKERS] [PATCH] Store Extension Options

2014-03-07 Thread Andres Freund
On 2014-03-07 19:14:48 -0300, Fabrízio de Royes Mello wrote: On Fri, Mar 7, 2014 at 5:56 PM, Alvaro Herrera alvhe...@2ndquadrant.comwrote: I am reworking this patch, both to accomodate earlier review comments and to fix the multiple verify step of namespaces, as noted by Tom in

Re: [HACKERS] [PATCH] Store Extension Options

2014-03-07 Thread Fabrízio de Royes Mello
On Fri, Mar 7, 2014 at 5:56 PM, Alvaro Herrera alvhe...@2ndquadrant.comwrote: I am reworking this patch, both to accomodate earlier review comments and to fix the multiple verify step of namespaces, as noted by Tom in 4530.1390023...@sss.pgh.pa.us Alvaro, Do you need some help? Regards,

Re: [HACKERS] [PATCH] Store Extension Options

2014-02-28 Thread Abhijit Menon-Sen
Hi Fabrízio. Here are a few comments based on a quick look at your updated patch. At 2014-02-13 22:44:56 -0200, fabriziome...@gmail.com wrote: diff --git a/doc/src/sgml/ref/alter_index.sgml b/doc/src/sgml/ref/alter_index.sgml index d210077..5e9ee9d 100644 ---

Re: [HACKERS] [PATCH] Store Extension Options

2014-02-28 Thread Fabrízio de Royes Mello
On Fri, Feb 28, 2014 at 5:08 AM, Abhijit Menon-Sen a...@2ndquadrant.com wrote: Hi Fabrízio. Here are a few comments based on a quick look at your updated patch. At 2014-02-13 22:44:56 -0200, fabriziome...@gmail.com wrote: diff --git a/doc/src/sgml/ref/alter_index.sgml

Re: [HACKERS] [PATCH] Store Extension Options

2014-02-13 Thread Fabrízio de Royes Mello
On Sun, Feb 9, 2014 at 2:22 PM, Fabrízio de Royes Mello fabriziome...@gmail.com wrote: On Sat, Jan 11, 2014 at 2:47 AM, Peter Eisentraut pete...@gmx.net wrote: On Sat, 2014-01-11 at 00:48 -0200, Fabrízio de Royes Mello wrote: Now, if bdr is installed but the validation doesn't happen

Re: [HACKERS] [PATCH] Store Extension Options

2014-02-09 Thread Fabrízio de Royes Mello
On Sat, Jan 11, 2014 at 2:47 AM, Peter Eisentraut pete...@gmx.net wrote: On Sat, 2014-01-11 at 00:48 -0200, Fabrízio de Royes Mello wrote: Now, if bdr is installed but the validation doesn't happen unless bdr is loaded in some sense, then that is an implementation deficiency that I

Re: [HACKERS] [PATCH] Store Extension Options

2014-01-10 Thread Fabrízio de Royes Mello
On Mon, Jan 6, 2014 at 1:50 AM, Tom Lane t...@sss.pgh.pa.us wrote: =?ISO-8859-1?Q?Fabr=EDzio_de_Royes_Mello?= fabriziome...@gmail.com writes: You are correct. pg_dump export reloptions using WITH clause of CREATE TABLE statement. I.e.: CREATE TABLE foo ( ) WITH

Re: [HACKERS] [PATCH] Store Extension Options

2014-01-10 Thread Peter Eisentraut
On Sat, 2014-01-11 at 00:48 -0200, Fabrízio de Royes Mello wrote: Now, if bdr is installed but the validation doesn't happen unless bdr is loaded in some sense, then that is an implementation deficiency that I think we can insist be rectified before this feature is accepted. Check if

Re: [HACKERS] [PATCH] Store Extension Options

2014-01-06 Thread Robert Haas
On Sun, Jan 5, 2014 at 10:50 PM, Tom Lane t...@sss.pgh.pa.us wrote: =?ISO-8859-1?Q?Fabr=EDzio_de_Royes_Mello?= fabriziome...@gmail.com writes: You are correct. pg_dump export reloptions using WITH clause of CREATE TABLE statement. I.e.: CREATE TABLE foo ( ) WITH (autovacuum_enabled=false,

Re: [HACKERS] [PATCH] Store Extension Options

2014-01-06 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes: On Sun, Jan 5, 2014 at 10:50 PM, Tom Lane t...@sss.pgh.pa.us wrote: Now, if bdr is installed but the validation doesn't happen unless bdr is loaded in some sense, then that is an implementation deficiency that I think we can insist be rectified before

Re: [HACKERS] [PATCH] Store Extension Options

2014-01-06 Thread Robert Haas
On Mon, Jan 6, 2014 at 2:58 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Sun, Jan 5, 2014 at 10:50 PM, Tom Lane t...@sss.pgh.pa.us wrote: Now, if bdr is installed but the validation doesn't happen unless bdr is loaded in some sense, then that is an

Re: [HACKERS] [PATCH] Store Extension Options

2014-01-06 Thread Jim Nasby
On 1/4/14, 12:00 PM, Tom Lane wrote: If you have some settings that need to be table-specific, then I agree that the reloptions infrastructure is a nice place to track them. What's actually missing here is some compelling examples of such settings for plausible extensions. I've got a real

Re: [HACKERS] [PATCH] Store Extension Options

2014-01-05 Thread Robert Haas
On Sat, Jan 4, 2014 at 1:00 PM, Tom Lane t...@sss.pgh.pa.us wrote: I would suggest addressing Robert's concern about lack of error checking by refusing to allow a custom reloption to be set unless the relevant extension is loaded and checks it. Unlike the postgresql.conf problem, I don't see

Re: [HACKERS] [PATCH] Store Extension Options

2014-01-05 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes: On Sat, Jan 4, 2014 at 1:00 PM, Tom Lane t...@sss.pgh.pa.us wrote: I would suggest addressing Robert's concern about lack of error checking by refusing to allow a custom reloption to be set unless the relevant extension is loaded and checks it. Unlike

Re: [HACKERS] [PATCH] Store Extension Options

2014-01-05 Thread Robert Haas
On Sun, Jan 5, 2014 at 3:45 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Sat, Jan 4, 2014 at 1:00 PM, Tom Lane t...@sss.pgh.pa.us wrote: I would suggest addressing Robert's concern about lack of error checking by refusing to allow a custom reloption to be

Re: [HACKERS] [PATCH] Store Extension Options

2014-01-05 Thread Fabrízio de Royes Mello
On Mon, Jan 6, 2014 at 1:08 AM, Robert Haas robertmh...@gmail.com wrote: On Sun, Jan 5, 2014 at 3:45 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Sat, Jan 4, 2014 at 1:00 PM, Tom Lane t...@sss.pgh.pa.us wrote: I would suggest addressing Robert's

Re: [HACKERS] [PATCH] Store Extension Options

2014-01-05 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes: On Sun, Jan 5, 2014 at 3:45 PM, Tom Lane t...@sss.pgh.pa.us wrote: pg_dump creates extensions before tables, no? So what dump/restore hazard? Creating the extension doesn't guarantee that the shared library will always be loaded. No, but unless the

Re: [HACKERS] [PATCH] Store Extension Options

2014-01-05 Thread Tom Lane
=?ISO-8859-1?Q?Fabr=EDzio_de_Royes_Mello?= fabriziome...@gmail.com writes: You are correct. pg_dump export reloptions using WITH clause of CREATE TABLE statement. I.e.: CREATE TABLE foo ( ) WITH (autovacuum_enabled=false, bdr.do_replicate=false); So if this statement checks for 'bdr'

Re: [HACKERS] [PATCH] Store Extension Options

2014-01-04 Thread Fabrizio Mello
Enviado via iPhone Em 02/01/2014, às 22:16, Robert Haas robertmh...@gmail.com escreveu: On Thu, Jan 2, 2014 at 4:19 AM, Andres Freund and...@2ndquadrant.com wrote: On 2013-12-31 13:37:59 +0100, Pavel Stehule wrote: We use the namespace ext to the internal code

Re: [HACKERS] [PATCH] Store Extension Options

2014-01-04 Thread Robert Haas
On Sat, Jan 4, 2014 at 11:07 AM, Fabrizio Mello fabriziome...@gmail.com wrote: I continue to think that the case for having this feature at all has not been well-made. We can use this feature to store any custom GUC for relations, attributes and functions also. Some use cases: * extension

Re: [HACKERS] [PATCH] Store Extension Options

2014-01-04 Thread Andres Freund
On 2014-01-04 11:54:46 -0500, Robert Haas wrote: On Sat, Jan 4, 2014 at 11:07 AM, Fabrizio Mello fabriziome...@gmail.com wrote: I continue to think that the case for having this feature at all has not been well-made. We can use this feature to store any custom GUC for relations,

Re: [HACKERS] [PATCH] Store Extension Options

2014-01-04 Thread Tom Lane
Andres Freund and...@2ndquadrant.com writes: On 2014-01-04 11:54:46 -0500, Robert Haas wrote: Well, as I said before, somebody can make their own configuration table and store stuff there, rather than using pg_class.reloptions. As I recall, the only response to that proposal was well, they

Re: [HACKERS] [PATCH] Store Extension Options

2014-01-04 Thread Andres Freund
On 2014-01-04 13:00:03 -0500, Tom Lane wrote: Andres Freund and...@2ndquadrant.com writes: On 2014-01-04 11:54:46 -0500, Robert Haas wrote: Well, as I said before, somebody can make their own configuration table and store stuff there, rather than using pg_class.reloptions. As I recall,

Re: [HACKERS] [PATCH] Store Extension Options

2014-01-04 Thread Tom Lane
Andres Freund and...@2ndquadrant.com writes: On 2014-01-04 13:00:03 -0500, Tom Lane wrote: Assuming that such examples are forthcoming, though, I think my main objection to this proposal is the ext. prefix, which seems precisely 100% useless, not to mention inconsistent with the naming of

Re: [HACKERS] [PATCH] Store Extension Options

2014-01-04 Thread Andres Freund
On 2014-01-04 14:06:19 -0500, Tom Lane wrote: Andres Freund and...@2ndquadrant.com writes: On 2014-01-04 13:00:03 -0500, Tom Lane wrote: Assuming that such examples are forthcoming, though, I think my main objection to this proposal is the ext. prefix, which seems precisely 100% useless,

Re: [HACKERS] [PATCH] Store Extension Options

2014-01-04 Thread Tom Lane
Andres Freund and...@2ndquadrant.com writes: On 2014-01-04 14:06:19 -0500, Tom Lane wrote: And if we have ext. as a prefix, exactly what prevents conflicts in the second part of the name? Nothing, that's what. It's useless. Uh? We are certainly not going to add core code that defines

Re: [HACKERS] [PATCH] Store Extension Options

2014-01-02 Thread Andres Freund
On 2013-12-31 13:37:59 +0100, Pavel Stehule wrote: We use the namespace ext to the internal code (src/backend/access/common/reloptions.c) skip some validations and store the custom GUC. Do you think we don't need to use the ext namespace? yes - there be same mechanism as we use for

Re: [HACKERS] [PATCH] Store Extension Options

2014-01-02 Thread Fabrízio de Royes Mello
On Thu, Jan 2, 2014 at 7:19 AM, Andres Freund and...@2ndquadrant.com wrote: On 2013-12-31 13:37:59 +0100, Pavel Stehule wrote: We use the namespace ext to the internal code (src/backend/access/common/reloptions.c) skip some validations and store the custom GUC. Do you think we

Re: [HACKERS] [PATCH] Store Extension Options

2014-01-02 Thread Andres Freund
On 2014-01-02 08:26:20 -0200, Fabrízio de Royes Mello wrote: On Thu, Jan 2, 2014 at 7:19 AM, Andres Freund and...@2ndquadrant.com wrote: On 2013-12-31 13:37:59 +0100, Pavel Stehule wrote: We use the namespace ext to the internal code (src/backend/access/common/reloptions.c) skip

Re: [HACKERS] [PATCH] Store Extension Options

2014-01-02 Thread Robert Haas
On Thu, Jan 2, 2014 at 4:19 AM, Andres Freund and...@2ndquadrant.com wrote: On 2013-12-31 13:37:59 +0100, Pavel Stehule wrote: We use the namespace ext to the internal code (src/backend/access/common/reloptions.c) skip some validations and store the custom GUC. Do you think we don't

[HACKERS] [PATCH] Store Extension Options

2013-12-31 Thread Pavel Stehule
Hello I am looking on this patch ALTER TABLE foo SET (ext.somext.do_replicate=true); Why is there fixed prefix ext ? This feature is similar to attaching setting to function CREATE OR REPLACE FUNCTION ... SET var = ...; We can use someprefix.someguc without problems there. Regards Pavel

Re: [HACKERS] [PATCH] Store Extension Options

2013-12-31 Thread Fabrízio de Royes Mello
On Tue, Dec 31, 2013 at 9:08 AM, Pavel Stehule pavel.steh...@gmail.com wrote: Hello I am looking on this patch ALTER TABLE foo SET (ext.somext.do_replicate=true); Why is there fixed prefix ext ? This feature is similar to attaching setting to function CREATE OR REPLACE FUNCTION ... SET

Re: [HACKERS] [PATCH] Store Extension Options

2013-12-31 Thread Pavel Stehule
2013/12/31 Fabrízio de Royes Mello fabriziome...@gmail.com On Tue, Dec 31, 2013 at 9:08 AM, Pavel Stehule pavel.steh...@gmail.com wrote: Hello I am looking on this patch ALTER TABLE foo SET (ext.somext.do_replicate=true); Why is there fixed prefix ext ? This feature is

Re: [HACKERS] [PATCH] Store Extension Options

2013-12-31 Thread Fabrízio de Royes Mello
On Tue, Dec 31, 2013 at 9:38 AM, Pavel Stehule pavel.steh...@gmail.com wrote: 2013/12/31 Fabrízio de Royes Mello fabriziome...@gmail.com On Tue, Dec 31, 2013 at 9:08 AM, Pavel Stehule pavel.steh...@gmail.com wrote: Hello I am looking on this patch ALTER TABLE foo SET

Re: [HACKERS] [PATCH] Store Extension Options

2013-12-31 Thread Pavel Stehule
2013/12/31 Fabrízio de Royes Mello fabriziome...@gmail.com On Tue, Dec 31, 2013 at 9:38 AM, Pavel Stehule pavel.steh...@gmail.com wrote: 2013/12/31 Fabrízio de Royes Mello fabriziome...@gmail.com On Tue, Dec 31, 2013 at 9:08 AM, Pavel Stehule pavel.steh...@gmail.com wrote:

Re: [HACKERS] [PATCH] Store Extension Options

2013-12-31 Thread Fabrízio de Royes Mello
On Tue, Dec 31, 2013 at 10:37 AM, Pavel Stehule pavel.steh...@gmail.com wrote: 2013/12/31 Fabrízio de Royes Mello fabriziome...@gmail.com On Tue, Dec 31, 2013 at 9:38 AM, Pavel Stehule pavel.steh...@gmail.com wrote: 2013/12/31 Fabrízio de Royes Mello fabriziome...@gmail.com On Tue, Dec

Re: [HACKERS] [PATCH] Store Extension Options

2013-12-31 Thread Pavel Stehule
2013/12/31 Fabrízio de Royes Mello fabriziome...@gmail.com On Tue, Dec 31, 2013 at 10:37 AM, Pavel Stehule pavel.steh...@gmail.com wrote: 2013/12/31 Fabrízio de Royes Mello fabriziome...@gmail.com On Tue, Dec 31, 2013 at 9:38 AM, Pavel Stehule pavel.steh...@gmail.com wrote:

Re: [HACKERS] [PATCH] Store Extension Options

2013-11-22 Thread Fabrízio de Royes Mello
On Thu, Nov 21, 2013 at 11:06 AM, Robert Haas robertmh...@gmail.com wrote: On Wed, Nov 20, 2013 at 9:35 PM, Fabrízio de Royes Mello fabriziome...@gmail.com wrote: So, with this patch we can do that: ALTER TABLE foo SET (ext.somext.do_replicate=true); When 'ext' is the fixed

Re: [HACKERS] [PATCH] Store Extension Options

2013-11-21 Thread Robert Haas
On Wed, Nov 20, 2013 at 9:35 PM, Fabrízio de Royes Mello fabriziome...@gmail.com wrote: So, with this patch we can do that: ALTER TABLE foo SET (ext.somext.do_replicate=true); When 'ext' is the fixed prefix, 'somext' is the extension name, 'do_replicate' is the extension option

[HACKERS] [PATCH] Store Extension Options

2013-11-20 Thread Fabrízio de Royes Mello
Hi all, The main goal of this patch is enable to an user the capability to store options (relations and attributes) related to extensions by using a fixed prefix called 'ext' in the defined name. It's cant be useful for replication solutions. So, with this patch we can do that: ALTER TABLE foo

Re: [HACKERS] [PATCH] Store Extension Options

2013-11-20 Thread Robert Haas
On Wed, Nov 20, 2013 at 1:52 PM, Fabrízio de Royes Mello fabriziome...@gmail.com wrote: The main goal of this patch is enable to an user the capability to store options (relations and attributes) related to extensions by using a fixed prefix called 'ext' in the defined name. It's cant be

Re: [HACKERS] [PATCH] Store Extension Options

2013-11-20 Thread Fabrízio de Royes Mello
On Thu, Nov 21, 2013 at 12:05 AM, Robert Haas robertmh...@gmail.com wrote: On Wed, Nov 20, 2013 at 1:52 PM, Fabrízio de Royes Mello fabriziome...@gmail.com wrote: The main goal of this patch is enable to an user the capability to store options (relations and attributes) related to