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 = ...
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
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
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
90 matches
Mail list logo
