On Thu, Mar 13, 2014 at 5:35 PM, Robert Haas 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 the validator can'
On Thu, Mar 13, 2014 at 11:30 AM, Alvaro Herrera
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 it's the
>> extensi
On Thu, Mar 13, 2014 at 11:37 AM, Andres Freund 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 before it restores
On Thu, Mar 13, 2014 at 11:42 AM, Andres Freund wrote:
> On 2014-03-13 11:26:10 -0400, Robert Haas wrote:
>> On Thu, Mar 13, 2014 at 11:11 AM, Tom Lane 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 ce
On Thu, Mar 13, 2014 at 12:11 PM, Tom Lane wrote:
> Andres Freund 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 catc
Andres Freund 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 catcache invalidations
On 2014-03-13 11:26:10 -0400, Robert Haas wrote:
> On Thu, Mar 13, 2014 at 11:11 AM, Tom Lane 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 existing inval
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
On 2014-03-13 11:15:56 -0400, Robert Haas wrote:
> On Thu, Mar 13, 2014 at 10:27 AM, Andres Freund
> wrote:
> > On 2014-03-13 10:24:09 -0400, Tom Lane wrote:
> >> Andres Freund writes:
> >> > But security labels are a nice idea, will think about it. AFAICs there's
> >> > no builtin subdivision w
On Thu, Mar 13, 2014 at 11:11 AM, Tom Lane wrote:
> Andres Freund 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 tha
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
> exte
On 2014-03-13 11:11:51 -0400, Tom Lane wrote:
> Andres Freund 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
On Thu, Mar 13, 2014 at 10:45 AM, Andres Freund 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 require that
>> the p
On Thu, Mar 13, 2014 at 10:27 AM, Andres Freund wrote:
> On 2014-03-13 10:24:09 -0400, Tom Lane wrote:
>> Andres Freund 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 sham
Andres Freund 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 seem to be any
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
> se
On 13 March 2014 14:36, Simon Riggs 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.
--
Simon Riggs
On 2014-03-13 10:26:11 -0400, Tom Lane wrote:
> [ forgot to respond to this part ]
>
> Andres Freund 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 wi
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
>
On Thu, Mar 13, 2014 at 10:22 AM, Simon Riggs wrote:
> On 13 March 2014 13:17, Robert Haas 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, t
On 13 March 2014 14:03, Robert Haas wrote:
> On Thu, Mar 13, 2014 at 9:26 AM, Andres Freund 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 s
Andres Freund 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 provider is in
> {shared,
On 13 March 2014 13:17, Stephen Frost 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 doesn't help ac
On Thu, Mar 13, 2014 at 10:20 AM, Andres Freund 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. SECURITY LABEL F
On 2014-03-13 10:24:09 -0400, Tom Lane wrote:
> Andres Freund 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
[ forgot to respond to this part ]
Andres Freund 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 for security labels, I
On 13 March 2014 13:17, Robert Haas 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 wrong with the patch,
On 2014-03-13 10:03:03 -0400, Robert Haas wrote:
> On Thu, Mar 13, 2014 at 9:26 AM, Andres Freund 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 real
On Thu, Mar 13, 2014 at 9:26 AM, Andres Freund 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 that a) doesn'
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 p
On Thu, Mar 13, 2014 at 12:47 AM, Simon Riggs wrote:
> On 13 March 2014 02:14, Robert Haas 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 provid
* 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
On 13 March 2014 02:14, Robert Haas 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 freedom to do wh
On Wed, Mar 12, 2014 at 9:38 PM, Simon Riggs wrote:
> On 12 March 2014 22:58, Robert Haas 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 RU
On 12 March 2014 22:58, Robert Haas 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
> work with GUCs to be
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 pr
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
On Mon, Mar 10, 2014 at 9:33 PM, Alvaro Herrera
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 will be able to do the
On Tue, Mar 11, 2014 at 8:42 PM, Simon Riggs wrote:
>
> On 11 March 2014 18:33, Tom Lane wrote:
> > Simon Riggs 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
On 11 March 2014 18:33, Tom Lane wrote:
> Simon Riggs 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, yo
Simon Riggs 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 it once the
module do
On Tue, Mar 11, 2014 at 2:43 PM, Simon Riggs wrote:
>
> On 11 March 2014 17:26, Alvaro Herrera wrote:
> > Tom Lane escribió:
> >> =?ISO-8859-1?Q?Fabr=EDzio_de_Royes_Mello?=
writes:
> >> > You are correct. pg_dump export reloptions using "WITH" clause of
CREATE
> >> > TABLE statement. I.e.:
> >>
On 11 March 2014 17:26, Alvaro Herrera wrote:
> Tom Lane escribió:
>> =?ISO-8859-1?Q?Fabr=EDzio_de_Royes_Mello?= writes:
>> > You are correct. pg_dump export reloptions using "WITH" clause of CREATE
>> > TABLE statement. I.e.:
>>
>> > CREATE TABLE foo (
>> > )
>> > WITH (autovacuum_enabled=false,
Tom Lane escribió:
> =?ISO-8859-1?Q?Fabr=EDzio_de_Royes_Mello?= 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 c
Fabrízio de Royes Mello escribió:
> On Fri, Mar 7, 2014 at 5:56 PM, Alvaro Herrera
> wrote:
>
> > 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
On Fri, Mar 7, 2014 at 5:56 PM, Alvaro Herrera wrote:
> 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,
--
Fabrízio de Royes
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
> wrote:
>
> > 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.
On Fri, Mar 7, 2014 at 7:21 PM, Andres Freund wrote:
> 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 >wrote:
> >
> > > I am reworking this patch, both to accomodate earlier review comments
> > > and to fix the multiple verify step
On Fri, Mar 7, 2014 at 5:56 PM, Alvaro Herrera wrote:
> 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 Royes Mello
Consultoria/
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
--
Se
On Fri, Feb 28, 2014 at 5:08 AM, Abhijit Menon-Sen
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
b/doc/src/sgml/ref/alter_index
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
> --- a/doc/src/sgml/ref/alter_i
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 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 unle
On Sat, Jan 11, 2014 at 2:47 AM, Peter Eisentraut 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 thi
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.
> >
On Mon, Jan 6, 2014 at 1:50 AM, Tom Lane wrote:
>
> =?ISO-8859-1?Q?Fabr=EDzio_de_Royes_Mello?=
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)
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 world
On Mon, Jan 6, 2014 at 2:58 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Jan 5, 2014 at 10:50 PM, Tom Lane 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 ins
Robert Haas writes:
> On Sun, Jan 5, 2014 at 10:50 PM, Tom Lane 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.
> We
On Sun, Jan 5, 2014 at 10:50 PM, Tom Lane wrote:
> =?ISO-8859-1?Q?Fabr=EDzio_de_Royes_Mello?= 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);
>
>>
=?ISO-8859-1?Q?Fabr=EDzio_de_Royes_Mello?= 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' extension is loaded t
Robert Haas writes:
> On Sun, Jan 5, 2014 at 3:45 PM, Tom Lane 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 plan is that no validation happe
On Mon, Jan 6, 2014 at 1:08 AM, Robert Haas wrote:
>
> On Sun, Jan 5, 2014 at 3:45 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> On Sat, Jan 4, 2014 at 1:00 PM, Tom Lane wrote:
> >>> I would suggest addressing Robert's concern about lack of error
checking
> >>> by refusing to allow a custom
On Sun, Jan 5, 2014 at 3:45 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sat, Jan 4, 2014 at 1:00 PM, Tom Lane 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
Robert Haas writes:
> On Sat, Jan 4, 2014 at 1:00 PM, Tom Lane 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,
>>
On Sat, Jan 4, 2014 at 1:00 PM, Tom Lane 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 any very good u
Andres Freund 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 relation
> options with
On 2014-01-04 14:06:19 -0500, Tom Lane wrote:
> Andres Freund 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 me
Andres Freund 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 custom GUCs,
>> wh
On 2014-01-04 13:00:03 -0500, Tom Lane wrote:
> Andres Freund 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 resp
Andres Freund 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 might
>> not want
On 2014-01-04 11:54:46 -0500, Robert Haas wrote:
> On Sat, Jan 4, 2014 at 11:07 AM, Fabrizio Mello
> 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
On Sat, Jan 4, 2014 at 11:07 AM, Fabrizio Mello 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 options
> * c
Enviado via iPhone
> Em 02/01/2014, às 22:16, Robert Haas escreveu:
>
>> On Thu, Jan 2, 2014 at 4:19 AM, Andres Freund 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 valida
On Thu, Jan 2, 2014 at 4:19 AM, Andres Freund 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 need to
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
> 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 valid
On Thu, Jan 2, 2014 at 7:19 AM, Andres Freund
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
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 mechan
2013/12/31 Fabrízio de Royes Mello
>
> On Tue, Dec 31, 2013 at 10:37 AM, Pavel Stehule
> wrote:
> >
> > 2013/12/31 Fabrízio de Royes Mello
> >>
> >> On Tue, Dec 31, 2013 at 9:38 AM, Pavel Stehule
> wrote:
> >> >
> >> > 2013/12/31 Fabrízio de Royes Mello
> >> >>
> >> >> On Tue, Dec 31, 2013 at
On Tue, Dec 31, 2013 at 10:37 AM, Pavel Stehule
wrote:
>
> 2013/12/31 Fabrízio de Royes Mello
>>
>> On Tue, Dec 31, 2013 at 9:38 AM, Pavel Stehule
wrote:
>> >
>> > 2013/12/31 Fabrízio de Royes Mello
>> >>
>> >> On Tue, Dec 31, 2013 at 9:08 AM, Pavel Stehule <
pavel.steh...@gmail.com> wrote:
>>
2013/12/31 Fabrízio de Royes Mello
>
> On Tue, Dec 31, 2013 at 9:38 AM, Pavel Stehule
> wrote:
> >
> >
> > 2013/12/31 Fabrízio de Royes Mello
> >>
> >>
> >> On Tue, Dec 31, 2013 at 9:08 AM, Pavel Stehule
> wrote:
> >> >
> >> > Hello
> >> >
> >> > I am looking on this patch
> >> >
> >> > ALTER
On Tue, Dec 31, 2013 at 9:38 AM, Pavel Stehule
wrote:
>
>
> 2013/12/31 Fabrízio de Royes Mello
>>
>>
>> On Tue, Dec 31, 2013 at 9:08 AM, Pavel Stehule
wrote:
>> >
>> > Hello
>> >
>> > I am looking on this patch
>> >
>> > ALTER TABLE foo SET (ext.somext.do_replicate=true);
>> >
>> > Why is there
2013/12/31 Fabrízio de Royes Mello
>
> On Tue, Dec 31, 2013 at 9:08 AM, Pavel Stehule
> 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 setti
On Tue, Dec 31, 2013 at 9:08 AM, Pavel Stehule
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 var = ...
On Thu, Nov 21, 2013 at 11:06 AM, Robert Haas wrote:
>
> On Wed, Nov 20, 2013 at 9:35 PM, Fabrízio de Royes Mello
> 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'
On Wed, Nov 20, 2013 at 9:35 PM, Fabrízio de Royes Mello
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
On Thu, Nov 21, 2013 at 12:05 AM, Robert Haas wrote:
>
> On Wed, Nov 20, 2013 at 1:52 PM, Fabrízio de Royes Mello
> 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
> > call
On Wed, Nov 20, 2013 at 1:52 PM, Fabrízio de Royes Mello
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 useful for replication
88 matches
Mail list logo
