On Thu, Nov 27, 2014 at 10:16 AM, Bruce Momjian br...@momjian.us wrote:
On Sat, Nov 8, 2014 at 05:56:00PM +0100, Andres Freund wrote:
On 2014-11-08 11:52:43 -0500, Tom Lane wrote:
Adding a similar
level of burden to support a feature with a narrow use-case seems like
a nonstarter from
Normally you would replicate between an older master and a newer
replica, so this shouldn't be an issue. I find it unlikely that we
would de-support some syntax that works in an older version: it would
break pg_dump, for one thing.
The most common way in which we break forward-compatibility
On Wed, Nov 26, 2014 at 09:01:13PM -0500, Stephen Frost wrote:
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
Bruce Momjian wrote:
How would replicating DDL handle cases where the master and slave
servers have different major versions and the DDL is only supported by
the Postgres
On Sat, Nov 8, 2014 at 05:56:00PM +0100, Andres Freund wrote:
On 2014-11-08 11:52:43 -0500, Tom Lane wrote:
Adding a similar
level of burden to support a feature with a narrow use-case seems like
a nonstarter from here.
I don't understand this statement. In my experience the lack of a
Bruce Momjian wrote:
On Sat, Nov 8, 2014 at 05:56:00PM +0100, Andres Freund wrote:
On 2014-11-08 11:52:43 -0500, Tom Lane wrote:
Adding a similar level of burden to support a feature with a
narrow use-case seems like a nonstarter from here.
I don't understand this statement. In my
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
Bruce Momjian wrote:
How would replicating DDL handle cases where the master and slave
servers have different major versions and the DDL is only supported by
the Postgres version on the master server?
Normally you would replicate between
On Fri, Nov 14, 2014 at 1:18 PM, Andres Freund and...@2ndquadrant.com wrote:
I think it's a good idea to structure independent features in a way that
other solutions can reuse them. But I sure as hell can't force them to
use it - especially as there's unfortunately not too much development
On Thu, Nov 13, 2014 at 7:45 AM, Andres Freund and...@2ndquadrant.com wrote:
Right. And that's why it's cool that logical decoding can operate
through DDL differences. The apply side might not be able to cope
with what pops out, but that's not logical decoding's fault, and
different
On 2014-11-14 12:38:52 -0500, Robert Haas wrote:
This is basically the same problem as multi-master replication
conflicts, except with DDL. Resolving replication conflicts is not a
very easy thing to get right even if you're only concerned about the
rows in the tables. It's probably
On Wed, Nov 12, 2014 at 4:58 PM, Andres Freund and...@2ndquadrant.com wrote:
That's already the situation today with all the logical replication
solutions. They *constantly* break in the field. Most commonly because
of DDL differences.
Right. And that's why it's cool that logical decoding can
On 2014-11-13 07:17:32 -0500, Robert Haas wrote:
On Wed, Nov 12, 2014 at 4:58 PM, Andres Freund and...@2ndquadrant.com wrote:
That's already the situation today with all the logical replication
solutions. They *constantly* break in the field. Most commonly because
of DDL differences.
On Mon, Nov 10, 2014 at 9:02 PM, Jim Nasby jim.na...@bluetreble.com wrote:
+1. Adding columns is a PITA, you have to manually ensure you do it on all
slaves first.
Drop is somewhat worse, because you have to do it on the master first,
opposite of the (more usual) case of adding a column.
On 2014-11-12 16:36:30 -0500, Robert Haas wrote:
On Mon, Nov 10, 2014 at 9:02 PM, Jim Nasby jim.na...@bluetreble.com wrote:
+1. Adding columns is a PITA, you have to manually ensure you do it on all
slaves first.
Drop is somewhat worse, because you have to do it on the master first,
On 8 November 2014 17:49, Robert Haas robertmh...@gmail.com wrote:
We could just integrate those parts, and be done with it. But would that
actually be a good thing for the community? Then slony needs to do it
and potentially others as well? Then auditing can't use it? Then
potential
On 10/11/14 23:37, Christopher Browne wrote:
On 8 November 2014 17:49, Robert Haas robertmh...@gmail.com
My impression, based on something Christopher Brown said a few years
ago, is that Slony's DDL trigger needs are largely satisfied by the
existing event trigger stuff. It would be
On 2014-11-10 17:37:40 -0500, Christopher Browne wrote:
On 8 November 2014 17:49, Robert Haas robertmh...@gmail.com wrote:
We could just integrate those parts, and be done with it. But would that
actually be a good thing for the community? Then slony needs to do it
and potentially others
On 11/10/14, 4:58 PM, Andres Freund wrote:
But the main reason all this is interesting isn't so much CREATE
itself. But that it can be (and Alvaro has mostly done it!) for ALTER as
well. And there it imo becomes really interesting. Because you can quite
easily check whether the affected relation
On 2014-11-07 21:41:17 -0500, Robert Haas wrote:
On Fri, Nov 7, 2014 at 10:45 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Michael Paquier wrote:
Here are more thoughts among those lines looking at the current state of
the patch 4 that introduces the infrastructure of the whole
On Sat, Nov 8, 2014 at 12:45 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Michael Paquier wrote:
Here are more thoughts among those lines looking at the current state of
the patch 4 that introduces the infrastructure of the whole feature. This
would make possible in-memory manipulation
On Sat, Nov 8, 2014 at 4:37 AM, Andres Freund and...@2ndquadrant.com wrote:
I don't understand why this is particularly difficult to regresssion
test. It actually is comparatively simple?
If it is, great. I previously wrote this email:
Robert Haas robertmh...@gmail.com writes:
If it were a question of writing this code once and being done with
it, that would be unobjectionable in my view. But it isn't.
Practically every change to gram.y is going to require a corresponding
change to this stuff. As far as I can see, nobody
On 2014-11-08 11:52:43 -0500, Tom Lane wrote:
Adding a similar
level of burden to support a feature with a narrow use-case seems like
a nonstarter from here.
I don't understand this statement. In my experience the lack of a usable
replication solution that allows temporary tables and major
Andres Freund and...@2ndquadrant.com writes:
On 2014-11-08 11:52:43 -0500, Tom Lane wrote:
Adding a similar
level of burden to support a feature with a narrow use-case seems like
a nonstarter from here.
I don't understand this statement. In my experience the lack of a usable
replication
On 2014-11-08 12:07:41 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-11-08 11:52:43 -0500, Tom Lane wrote:
Adding a similar
level of burden to support a feature with a narrow use-case seems like
a nonstarter from here.
I don't understand this statement.
On Sat, Nov 8, 2014 at 12:20 PM, Andres Freund and...@2ndquadrant.com wrote:
Putting half of it into core wouldn't fix that, it would just put a
lot more maintenance burden on core developers.
Imo stuff that can't be done sanely outside core needs to be put into
core if it's actually desired
On 2014-11-08 12:30:29 -0500, Robert Haas wrote:
On Sat, Nov 8, 2014 at 12:20 PM, Andres Freund and...@2ndquadrant.com wrote:
Putting half of it into core wouldn't fix that, it would just put a
lot more maintenance burden on core developers.
Imo stuff that can't be done sanely outside
On 2014-11-08 10:42:15 -0500, Robert Haas wrote:
On Sat, Nov 8, 2014 at 4:37 AM, Andres Freund and...@2ndquadrant.com wrote:
I don't understand why this is particularly difficult to regresssion
test. It actually is comparatively simple?
If it is, great. I previously wrote this email:
On Sat, Nov 8, 2014 at 1:05 PM, Andres Freund and...@2ndquadrant.com wrote:
There's nothing to keep you from exposing the parse trees to
C functions that can live in an extension, and you can do all of this
deparsing there.
Not really. There's some core functions that need to be touched. Like
On 2014-11-08 17:49:30 -0500, Robert Haas wrote:
Patch 2 adds support for GRANT and REVOKE to the event trigger
mechanism. I wonder if it's a bad idea to make the
ddl_command_start/end events fire for DCL. We discussed a lot of
these issues when this patch originally went in, and I think
On Sat, Nov 8, 2014 at 4:35 PM, Andres Freund and...@2ndquadrant.com wrote:
I don't understand why this is particularly difficult to regresssion
test. It actually is comparatively simple?
If it is, great. I previously wrote this email:
On Sat, Nov 8, 2014 at 6:24 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-11-08 17:49:30 -0500, Robert Haas wrote:
Patch 2 adds support for GRANT and REVOKE to the event trigger
mechanism. I wonder if it's a bad idea to make the
ddl_command_start/end events fire for DCL. We
Michael Paquier wrote:
Here are more thoughts among those lines looking at the current state of
the patch 4 that introduces the infrastructure of the whole feature. This
would make possible in-memory manipulation of jsonb containers without
relying on a 3rd-part set of APIs like what this
On Fri, Nov 7, 2014 at 10:45 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Michael Paquier wrote:
Here are more thoughts among those lines looking at the current state of
the patch 4 that introduces the infrastructure of the whole feature. This
would make possible in-memory manipulation
On Fri, Oct 31, 2014 at 11:27 AM, Michael Paquier michael.paqu...@gmail.com
wrote:
So, what I think is missing is really a friendly interface to manipulate
JsonbContainers directly, and I think that we are not far from it with
something like this set, roughly:
- Initialization of an empty
On Thu, Oct 30, 2014 at 2:40 AM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Oct 28, 2014 at 6:00 AM, Andres Freund and...@2ndquadrant.com
wrote:
Uhm. Obviously we didn't have jsonb when I started this and we do have
them now, so I could perhaps see about updating the patch to do
On Thu, Oct 16, 2014 at 4:01 PM, Michael Paquier michael.paqu...@gmail.com
wrote:
On Mon, Oct 13, 2014 at 12:45 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Here's a new version of this series.
Here is some input on patch 4:
1) Use of OBJECT_ATTRIBUTE:
+ case
Hi Michael, thanks for the review.
Michael Paquier wrote:
On Thu, Oct 16, 2014 at 4:01 PM, Michael Paquier michael.paqu...@gmail.com
wrote:
On Mon, Oct 13, 2014 at 12:45 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Here's a new version of this series.
Here is some input on
On 2014-10-28 05:30:43 -0300, Alvaro Herrera wrote:
A couple of comments: this patch introduces a basic infrastructure able to
do the following set of operations:
- Obtention of parse tree using StashedCommand
- Reorganization of parse tree to become an ObjTree, with boolean, array
-
On Mon, Oct 13, 2014 at 12:45 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Here's a new version of this series. The main change is that I've
changed deparse_utility.c to generate JSON, and the code that was in
commands/event_trigger.c to decode that JSON, so that it uses the new
Jsonb
On Thu, Oct 9, 2014 at 8:29 AM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Thu, Oct 9, 2014 at 6:26 AM, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:
However, if I were to do it, I would instead create a quote.h file and
would also add the quote_literal_cstr() prototype to it,
About patch 1, which I just pushed, there were two reviews:
Andres Freund wrote:
On 2014-09-25 18:59:31 -0300, Alvaro Herrera wrote:
diff --git a/src/include/utils/ruleutils.h b/src/include/utils/ruleutils.h
new file mode 100644
index 000..520b066
--- /dev/null
+++
On Thu, Oct 9, 2014 at 6:26 AM, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:
About patch 1, which I just pushed, there were two reviews:
Andres Freund wrote:
On 2014-09-25 18:59:31 -0300, Alvaro Herrera wrote:
diff --git a/src/include/utils/ruleutils.h
b/src/include/utils/ruleutils.h
On 2014-09-25 18:59:31 -0300, Alvaro Herrera wrote:
/* tid.c */
diff --git a/src/include/utils/ruleutils.h b/src/include/utils/ruleutils.h
new file mode 100644
index 000..520b066
--- /dev/null
+++ b/src/include/utils/ruleutils.h
@@ -0,0 +1,34 @@
On Fri, Sep 26, 2014 at 6:59 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Actually here's a different split of these patches, which I hope makes
more sense. My intention here is that patches 0001 to 0004 are simple
changes that can be pushed right away; they are not directly related to
On Tue, Aug 26, 2014 at 11:14 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
And a last one before lunch, closing the review for all the basic things...
Patch 13: Could you explain why this is necessary?
+extern PGDLLIMPORT bool creating_extension;
It may make sense by looking at the
On Tue, Aug 26, 2014 at 8:10 AM, Michael Paquier
michael.paqu...@gmail.com wrote:
Well, I like the patch series for what it counts as long as you can
submit it as such. That's far easier to test and certainly helps in
spotting issues when kicking different code paths.
So, for patch 2, which is
On Wed, Aug 27, 2014 at 1:10 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Tue, Aug 26, 2014 at 8:10 AM, Michael Paquier
michael.paqu...@gmail.com wrote:
Well, I like the patch series for what it counts as long as you can
submit it as such. That's far easier to test and certainly
On Sat, Jun 14, 2014 at 5:31 AM, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:
Here's a refreshed version of this patch. I have split it up in a
largish number of pieces, which hopefully makes it easier to understand
what is going on.
Alvaro,
Could you confirm that the patches you just
Michael Paquier wrote:
On Sat, Jun 14, 2014 at 5:31 AM, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:
Here's a refreshed version of this patch. I have split it up in a
largish number of pieces, which hopefully makes it easier to understand
what is going on.
Alvaro,
Could you
On Tue, Aug 26, 2014 at 5:33 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Michael Paquier wrote:
And 4. Yes, they are. I wanted to get trivial stuff out of the way
while I had some other trivial patch at hand. I'm dealing with another
patch from the commitfest now, so I'm not posting
On 2/6/14, 11:20 AM, Alvaro Herrera wrote:
NOTICE: JSON blob: {
definition: [
{
clause: owned,
fmt: OWNED BY %{owner}D,
owner: {
attrname: a,
objname: t1,
schemaname: public
}
Jim Nasby wrote:
On 2/6/14, 11:20 AM, Alvaro Herrera wrote:
NOTICE: JSON blob: {
definition: [
{
clause: owned,
fmt: OWNED BY %{owner}D,
owner: {
attrname: a,
objname: t1,
schemaname:
On Thu, Mar 13, 2014 at 5:06 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Alvaro Herrera escribió:
I also fixed the sequence OWNED BY problem simply by adding support for
ALTER SEQUENCE. Of course, the intention is that all forms of CREATE
and ALTER are supported, but this one seems
ca+tgmoayo1e2tjjefrvhgq6tmgpyhg_4loy_fwrzl8txxgf...@mail.gmail.com
Robert Haas wrote:
What does the colon-space in %{definition: }s mean?
It means it expects the definition element to be a JSON array, and
that it will format the elements by separating them with a space. In
other DDL commands,
On Fri, Mar 14, 2014 at 12:00 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
I don't think we should be worried about there being a lot of extra code
to write as DDL is added or modified. I do share your concern that
we're going to *forget* to write these things in the first place, unless
Alvaro Herrera escribió:
I also fixed the sequence OWNED BY problem simply by adding support for
ALTER SEQUENCE. Of course, the intention is that all forms of CREATE
and ALTER are supported, but this one seems reasonable standalone
because CREATE TABLE uses it internally.
I have been
On Thu, Feb 6, 2014 at 12:08 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Feb 5, 2014 at 2:26 PM, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:
Then again, why is the behavior of schema-qualifying absolutely
everything even desirable?
Well,
On Tue, Feb 4, 2014 at 12:11 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
I have run into some issues, though:
1. certain types, particularly timestamp/timestamptz but really this
could happen for any type, have unusual typmod output behavior. For
those one cannot just use the
Robert Haas escribió:
On Tue, Feb 4, 2014 at 12:11 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
I have run into some issues, though:
1. certain types, particularly timestamp/timestamptz but really this
could happen for any type, have unusual typmod output behavior. For
those one
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Robert Haas escribió:
How about doing whatever pg_dump does?
We use format_type() for that as far as I know. What it does
differently is use undecorated names defined by the standard for some
types, which are never schema qualified and are
On Wed, Feb 5, 2014 at 2:26 PM, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
Then again, why is the behavior of schema-qualifying absolutely
everything even desirable?
Well, someone could create a collation in another schema with the same
name as a system collation and the command would
Robert Haas robertmh...@gmail.com writes:
On Wed, Feb 5, 2014 at 2:26 PM, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:
Then again, why is the behavior of schema-qualifying absolutely
everything even desirable?
Well, someone could create a collation in another schema with the same
name as
Hi,
Alvaro Herrera alvhe...@2ndquadrant.com writes:
So here's a patch implementing the ideas expressed in this thread.
There are two new SQL functions:
I spent some time reviewing the patch and tried to focus on a higher
level review, as I saw Andres already began with the lower level stuff.
On 2014-01-15 02:11:11 -0300, Alvaro Herrera wrote:
Then execute commands to your liking.
So, I am giving a quick look, given that I very likely will have to
write a consumer for it...
* deparse_utility_command returns payload via parameter, not return
value?
* functions beginning with an
Andres Freund escribió:
* Why must we not schema qualify system types
(c.f. expand_jsonval_typename)? It seems to be perfectly sensible to
me to just use pg_catalog there.
So, the reason for doing things this way is to handle cases like
varchar(10) being turned into character varying; and
Alvaro Herrera alvhe...@2ndquadrant.com writes:
So, the reason for doing things this way is to handle cases like
varchar(10) being turned into character varying; and that name
requires that the typename NOT be schema-qualified, otherwise it fails.
But thinking about this again, I don't see a
Hello
2014/1/13 Alvaro Herrera alvhe...@2ndquadrant.com
Alvaro Herrera escribió:
In an event trigger, the function
pg_event_trigger_get_creation_commands()
returns the following JSON blob:
After playing with this for a while, I realized something that must have
seemed quite obvious to
On Fri, Jan 10, 2014 at 6:22 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Here's one idea: create a contrib module that (somehow, via APIs to be
invented) runs every DDL command that gets executed through the
deparsing code, and then parses the result and executes *that* instead
of the
On 1/14/14, 2:05 PM, Robert Haas wrote:
On Fri, Jan 10, 2014 at 6:22 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Here's one idea: create a contrib module that (somehow, via APIs to be
invented) runs every DDL command that gets executed through the
deparsing code, and then parses the
Alvaro Herrera escribió:
In an event trigger, the function pg_event_trigger_get_creation_commands()
returns the following JSON blob:
After playing with this for a while, I realized something that must have
seemed quite obvious to those paying attention: what this function is,
is just a
On 10 January 2014 23:22, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
On the subject of testing the triggers, Robert Haas wrote:
Here's one idea: create a contrib module that (somehow, via APIs to be
invented) runs every DDL command that gets executed through the
deparsing code, and then
On 8 January 2014 20:42, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
CREATE SCHEMA IF NOT EXISTS some schema AUTHORIZATION some guy;
Hmm, given in 9.3 it was OK to have only DROP event triggers, I think
it should be equally acceptable to have just CREATE, but without every
option on CREATE.
On Thu, Jan 9, 2014 at 5:17 PM, Jim Nasby j...@nasby.net wrote:
On 1/9/14, 11:58 AM, Alvaro Herrera wrote:
Robert Haas escribió:
On Wed, Jan 8, 2014 at 10:27 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Hmm. This seems like a reasonable thing to do, except that I would like
the
On Fri, Jan 10, 2014 at 10:36 AM, Simon Riggs si...@2ndquadrant.com wrote:
On 8 January 2014 20:42, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
CREATE SCHEMA IF NOT EXISTS some schema AUTHORIZATION some guy;
Hmm, given in 9.3 it was OK to have only DROP event triggers, I think
it should
On 10 January 2014 15:48, Robert Haas robertmh...@gmail.com wrote:
On Fri, Jan 10, 2014 at 10:36 AM, Simon Riggs si...@2ndquadrant.com wrote:
On 8 January 2014 20:42, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
CREATE SCHEMA IF NOT EXISTS some schema AUTHORIZATION some guy;
Hmm, given in
On Fri, Jan 10, 2014 at 10:55 AM, Simon Riggs si...@2ndquadrant.com wrote:
On 10 January 2014 15:48, Robert Haas robertmh...@gmail.com wrote:
On Fri, Jan 10, 2014 at 10:36 AM, Simon Riggs si...@2ndquadrant.com wrote:
On 8 January 2014 20:42, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
On 10 January 2014 17:07, Robert Haas robertmh...@gmail.com wrote:
On Fri, Jan 10, 2014 at 10:55 AM, Simon Riggs si...@2ndquadrant.com wrote:
On 10 January 2014 15:48, Robert Haas robertmh...@gmail.com wrote:
On Fri, Jan 10, 2014 at 10:36 AM, Simon Riggs si...@2ndquadrant.com wrote:
On 8
On Fri, Jan 10, 2014 at 12:59 PM, Simon Riggs si...@2ndquadrant.com wrote:
That's project policy
and always has been. When somebody implements 50% of a feature, or
worse yet 95% of a feature, it violates the POLA for users and doesn't
always subsequently get completed, leaving us with
On 10 January 2014 18:17, Robert Haas robertmh...@gmail.com wrote:
On Fri, Jan 10, 2014 at 12:59 PM, Simon Riggs si...@2ndquadrant.com wrote:
That's project policy
and always has been. When somebody implements 50% of a feature, or
worse yet 95% of a feature, it violates the POLA for users and
Can we please stop arguing over a problem I don't have? I started with
CREATE SCHEMA because it is one of the easy cases, not because it was
the most difficult case: we only need to deparse the bits of it that
don't involve the objects within, because those are reported by the
event trigger as
On 1/10/14, 3:40 PM, Simon Riggs wrote:
Given that CREATE SCHEMA with multiple objects is less well used, its
a reasonable restriction to accept for one release, if the alternative
is to implement nothing at all of value. Especially since we are now
in the third year of development of this set
On 1/10/14, 5:22 PM, Alvaro Herrera wrote:
Here's one idea: create a contrib module that (somehow, via APIs to be
invented) runs every DDL command that gets executed through the
deparsing code, and then parses the result and executes*that* instead
of the original command. Then, add a build
On Wed, Jan 8, 2014 at 10:27 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Craig Ringer escribió:
Instead, can't we use your already proposed subclause structure?
{authorization:{authorization_role:some guy,
output:AUTHORIZATION %i{authorization_role}},
if_not_exists:
Robert Haas escribió:
On Wed, Jan 8, 2014 at 10:27 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Hmm. This seems like a reasonable thing to do, except that I would like
the output to always be the constant, and have some other way to
enable the clause or disable it. With your
On 1/9/14, 11:58 AM, Alvaro Herrera wrote:
Robert Haas escribió:
On Wed, Jan 8, 2014 at 10:27 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Hmm. This seems like a reasonable thing to do, except that I would like
the output to always be the constant, and have some other way to
enable
Alvaro Herrera escribió:
Robert Haas escribió:
I think this direction has some potential. I'm not sure it's right in
detail. The exact scheme you propose above won't work if you want to
leave out the schema name altogether, and more generally it's not
going to help very much with
Hello
I don't like this direction. What we can do with JSON from plpgsql? More,
JSON is not too robust format against some future changes.
Regards
Pavel
Dne 8.1.2014 21:43 Alvaro Herrera alvhe...@2ndquadrant.com napsal(a):
Alvaro Herrera escribió:
Robert Haas escribió:
I think this
Pavel Stehule escribió:
Hello
I don't like this direction. What we can do with JSON from plpgsql?
We have plenty of JSON functions and operators in SQL, and more to come
soon. Is that not enough?
More, JSON is not too robust format against some future changes.
Not sure what you mean.
CC to hackers restored.
Pavel Stehule escribió:
Dne 8.1.2014 23:17 Alvaro Herrera alvhe...@2ndquadrant.com napsal(a):
Pavel Stehule escribió:
Hello
I don't like this direction. What we can do with JSON from plpgsql?
We have plenty of JSON functions and operators in SQL, and more
On 01/09/2014 04:42 AM, Alvaro Herrera wrote:
If there's a NULL element when expanding an object, the whole thing
expands to empty. For example, if no AUTHORIZATION
clause is specified, authorization element is still there, but the
authorization_role element within it is NULL, and so the
Craig Ringer escribió:
Instead, can't we use your already proposed subclause structure?
{authorization:{authorization_role:some guy,
output:AUTHORIZATION %i{authorization_role}},
if_not_exists: {output: IF NOT EXISTS},
name:some schema,
output:CREATE SCHEMA
On Fri, Jan 3, 2014 at 9:05 AM, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
The other thing that bothers me here is that, while a normalized
command string sounds great in theory, as soon as you want to allow
(for example) mapping schema A on node 1 to schema B on node 2, the
wheels come
Robert Haas escribió:
I think this direction has some potential. I'm not sure it's right in
detail. The exact scheme you propose above won't work if you want to
leave out the schema name altogether, and more generally it's not
going to help very much with anything other than substituting in
On Mon, Jan 6, 2014 at 1:17 PM, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
I agree, except that I would prefer not to have one function for each
DDL statement type; instead we would have a single function that knows
to expand arbitrary strings using arbitrary JSON parameter objects, and
Robert Haas escribió:
The other thing that bothers me here is that, while a normalized
command string sounds great in theory, as soon as you want to allow
(for example) mapping schema A on node 1 to schema B on node 2, the
wheels come off: you'll have to deparse that normalized command string
On Thu, Nov 21, 2013 at 2:36 AM, Christopher Browne cbbro...@gmail.com wrote:
b) What's the best design of the SRF output? This patch proposes two
columns, object identity and create statement. Is there use for
anything else? Class/object OIDs perhaps, schema OIDs for objects types
that
On Fri, Nov 8, 2013 at 10:33 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Hello,
Attached you can find a very-much-WIP patch to add CREATE info support
for event triggers (normalized commands). This patch builds mainly on
two things:
1. Dimitri's DDL rewrite patch he submitted way
On Fri, Nov 8, 2013 at 10:33 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Attached you can find a very-much-WIP patch to add CREATE info support
for event triggers (normalized commands). This patch builds mainly on
two things:
1. Dimitri's DDL rewrite patch he submitted way back, in
98 matches
Mail list logo
