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
* 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
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
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
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
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,
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
[ 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
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
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.
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
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
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
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
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 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
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.
--
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
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
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
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
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
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
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,
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
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: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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
--
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
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
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
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,
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
---
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
=?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'
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
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
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,
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
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,
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
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,
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
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
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
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
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
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 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
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
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
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:
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
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:
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
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
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
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
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
90 matches
Mail list logo
