On Thu, Nov 27, 2014 at 10:16 AM, 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.
>>
> 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-compatibili
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
* 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
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 statem
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 lac
On Fri, Nov 14, 2014 at 1:18 PM, Andres Freund 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
> going on in the existi
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 pr
On Thu, Nov 13, 2014 at 7:45 AM, Andres Freund 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 apply-sides can adopt d
On 2014-11-13 07:17:32 -0500, Robert Haas wrote:
> On Wed, Nov 12, 2014 at 4:58 PM, Andres Freund 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'
On Wed, Nov 12, 2014 at 4:58 PM, Andres Freund 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 operate
through DDL
On 2014-11-12 16:36:30 -0500, Robert Haas wrote:
> On Mon, Nov 10, 2014 at 9:02 PM, Jim Nasby 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 (
On Mon, Nov 10, 2014 at 9:02 PM, Jim Nasby 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.
>
> RENAME is a complete
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-10 17:37:40 -0500, Christopher Browne wrote:
> On 8 November 2014 17:49, Robert Haas 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? Th
On 10/11/14 23:37, Christopher Browne wrote:
On 8 November 2014 17:49, Robert Haas
> 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 helpful to get confirmat
On 8 November 2014 17:49, Robert Haas 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 schema tracking sol
On Sat, Nov 8, 2014 at 6:24 PM, Andres Freund 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 discussed a lot of
>> t
On Sat, Nov 8, 2014 at 4:35 PM, Andres Freund 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:
>>
>> http://www.postgresql.org/message-id/CA+TgmoZ=vzrijmxlkqi_v0jg
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 1:05 PM, Andres Freund 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
> most of the
On 2014-11-08 10:42:15 -0500, Robert Haas wrote:
> On Sat, Nov 8, 2014 at 4:37 AM, Andres Freund 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:
>
> http://www.post
On 2014-11-08 12:30:29 -0500, Robert Haas wrote:
> On Sat, Nov 8, 2014 at 12:20 PM, Andres Freund 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 b
On Sat, Nov 8, 2014 at 12:20 PM, Andres Freund 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 by many users. A
On 2014-11-08 12:07:41 -0500, Tom Lane wrote:
> Andres Freund 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 exp
Andres Freund 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 solution that all
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 v
Robert Haas 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 except me has
> com
On Sat, Nov 8, 2014 at 4:37 AM, Andres Freund 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:
http://www.postgresql.org/message-id/CA+TgmoZ=vzrijmxlkqi_v0jg4k4leapmwusc6rwx
On Sat, Nov 8, 2014 at 12:45 AM, Alvaro Herrera
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 of jsonb containe
On 2014-11-07 21:41:17 -0500, Robert Haas wrote:
> On Fri, Nov 7, 2014 at 10:45 AM, Alvaro Herrera
> 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
>
On Fri, Nov 7, 2014 at 10:45 AM, Alvaro Herrera
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 of jsonb containe
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, Oct 31, 2014 at 11:27 AM, Michael Paquier 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 container
> - Set of APIs
On Thu, Oct 30, 2014 at 2:40 AM, Robert Haas wrote:
> On Tue, Oct 28, 2014 at 6:00 AM, Andres Freund
> 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 things
> >> this way; but I'm not totall
On Tue, Oct 28, 2014 at 6:00 AM, Andres Freund 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 things
>> this way; but I'm not totally sold on that idea, as my ObjTree stuff is
>> a lot easier to m
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
Hi Michael, thanks for the review.
Michael Paquier wrote:
> On Thu, Oct 16, 2014 at 4:01 PM, Michael Paquier
> wrote:
>
> > On Mon, Oct 13, 2014 at 12:45 PM, Alvaro Herrera
> > wrote:
> > > Here's a new version of this series.
>
> Here is some input on patch 4:
>
> 1) Use of OBJECT_ATTRIBUTE
On Thu, Oct 16, 2014 at 4:01 PM, Michael Paquier
wrote:
> On Mon, Oct 13, 2014 at 12:45 PM, Alvaro Herrera
> wrote:
> > Here's a new version of this series.
Here is some input on patch 4:
1) Use of OBJECT_ATTRIBUTE:
+ case OBJECT_ATTRIBUTE:
+ catalog_id = T
On Mon, Oct 13, 2014 at 12:45 PM, Alvaro Herrera
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 API instead. In addit
On Thu, Oct 9, 2014 at 8:29 AM, Michael Paquier
wrote:
> On Thu, Oct 9, 2014 at 6:26 AM, Alvaro Herrera
> 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, perhaps even
>> move the implementations from thei
On Thu, Oct 9, 2014 at 6:26 AM, Alvaro Herrera
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
> > > new file mo
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
> > +++ b/src/
On Fri, Sep 26, 2014 at 6:59 AM, Alvaro Herrera
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
> the return-creation-c
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 Tue, Aug 26, 2014 at 11:14 PM, Michael Paquier
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 core features (then why i
On Wed, Aug 27, 2014 at 1:10 PM, Michael Paquier
wrote:
> On Tue, Aug 26, 2014 at 8:10 AM, Michael Paquier
> 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 differe
On Tue, Aug 26, 2014 at 8:10 AM, Michael Paquier
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 a cosmetic change for
On Tue, Aug 26, 2014 at 5:33 AM, Alvaro Herrera
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 a rebased version
> r
Michael Paquier wrote:
> On Sat, Jun 14, 2014 at 5:31 AM, Alvaro Herrera
> 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 th
On Sat, Jun 14, 2014 at 5:31 AM, Alvaro Herrera
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 committed are 1, 3 and 6
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":
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": "pu
On Fri, Mar 14, 2014 at 12:00 PM, Alvaro Herrera
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
> we do something to a
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, there are things like %{table_element:, }s which
means to sepa
On Thu, Mar 13, 2014 at 5:06 PM, Alvaro Herrera
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 reasonable standalo
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 hac
On Thu, Feb 6, 2014 at 12:08 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Feb 5, 2014 at 2:26 PM, Alvaro Herrera
>> wrote:
Then again, why is the behavior of schema-qualifying absolutely
everything even desirable?
>
>>> Well, someone could create a collation in another schema
Robert Haas writes:
> On Wed, Feb 5, 2014 at 2:26 PM, Alvaro Herrera
> 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 comman
On Wed, Feb 5, 2014 at 2:26 PM, Alvaro Herrera 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 become ambiguous. Fo
Alvaro Herrera 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 never ambiguous becaus
Robert Haas escribió:
> On Tue, Feb 4, 2014 at 12:11 AM, Alvaro Herrera
> 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
On Tue, Feb 4, 2014 at 12:11 AM, Alvaro Herrera
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 schema-qualified catalog nam
Hi,
Alvaro Herrera 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.
The main things to keep
Alvaro Herrera 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 reason why this ca
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
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 und
On 1/14/14, 2:05 PM, Robert Haas wrote:
On Fri, Jan 10, 2014 at 6: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* in
On Fri, Jan 10, 2014 at 6: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.
Hello
2014/1/13 Alvaro Herrera
> 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 a
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 glorif
On 10 January 2014 23:22, Alvaro Herrera 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 parses the result
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 t
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 of
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 se
On 10 January 2014 18:17, Robert Haas wrote:
> On Fri, Jan 10, 2014 at 12:59 PM, Simon Riggs 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
On Fri, Jan 10, 2014 at 12:59 PM, Simon Riggs 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 long-term warts
>> th
On 10 January 2014 17:07, Robert Haas wrote:
> On Fri, Jan 10, 2014 at 10:55 AM, Simon Riggs wrote:
>> On 10 January 2014 15:48, Robert Haas wrote:
>>> On Fri, Jan 10, 2014 at 10:36 AM, Simon Riggs wrote:
On 8 January 2014 20:42, Alvaro Herrera wrote:
> CREATE SCHEMA IF NOT EXIST
On Fri, Jan 10, 2014 at 10:55 AM, Simon Riggs wrote:
> On 10 January 2014 15:48, Robert Haas wrote:
>> On Fri, Jan 10, 2014 at 10:36 AM, Simon Riggs wrote:
>>> On 8 January 2014 20:42, Alvaro Herrera wrote:
>>>
CREATE SCHEMA IF NOT EXISTS "some schema" AUTHORIZATION "some guy";
>>>
>>> Hmm
On 10 January 2014 15:48, Robert Haas wrote:
> On Fri, Jan 10, 2014 at 10:36 AM, Simon Riggs wrote:
>> On 8 January 2014 20:42, Alvaro Herrera 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 t
On Fri, Jan 10, 2014 at 10:36 AM, Simon Riggs wrote:
> On 8 January 2014 20:42, Alvaro Herrera 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 C
On Thu, Jan 9, 2014 at 5:17 PM, Jim Nasby 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
>>> wrote:
>>
>>
Hmm. This seems like a reasonable thing to do, except that I would like
the "output" to always
On 8 January 2014 20:42, Alvaro Herrera 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. CREATE SCHEMA is ea
On 1/9/14, 11:58 AM, Alvaro Herrera wrote:
Robert Haas escribió:
On Wed, Jan 8, 2014 at 10:27 PM, Alvaro Herrera
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.
Robert Haas escribió:
> On Wed, Jan 8, 2014 at 10:27 PM, Alvaro Herrera
> 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 "present" boolean:
>
On Wed, Jan 8, 2014 at 10:27 PM, Alvaro Herrera
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": {
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",
> "outp
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
CC to hackers restored.
Pavel Stehule escribió:
> Dne 8.1.2014 23:17 "Alvaro Herrera" 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 to c
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.
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" napsal(a):
> Alvaro Herrera escribió:
> > Robert Haas escribió:
> >
> > > I think this direction has some
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
On Mon, Jan 6, 2014 at 1:17 PM, Alvaro Herrera 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
> let ddl_rewrite.c (or w
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
On Fri, Jan 3, 2014 at 9:05 AM, Alvaro Herrera 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 off: you'll have to
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 str
On Thu, Nov 21, 2013 at 2:36 AM, Christopher Browne 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 have it? I do
On Fri, Nov 8, 2013 at 10:33 AM, Alvaro Herrera
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 back, in
>http
On Fri, Nov 8, 2013 at 10:33 AM, Alvaro Herrera
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
>http://www.post
99 matches
Mail list logo
