Re: Add CREATE support to event triggers - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: Add CREATE support to event triggers
Date
Msg-id CAFj8pRC6s3=b2T+3=2EC8N9CXSW8V7Q7c6V3g_2b3F=Z6dGTLw@mail.gmail.com
Whole thread Raw
In response to Re: Add CREATE support to event triggers  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: Add CREATE support to event triggers  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
Hello


2014/1/13 Alvaro Herrera <alvherre@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 those paying attention: what this function is,
is just a glorified sprintf() for JSON.  So I propose we take our
existing format(text) and use it to model a new format(json) function,
which will be useful to the project at hand and be of more general
applicability.

To make it a better fit, I have changed the spec slightly.  The format
string is now the "fmt" element in the topmost JSON.  This format string
can contain % escapes, which consist of:

* the literal % itself
* an element name, enclosed in braces { }.  The name can optionally be
  followed by a colon and a possibly-empty array separator.
* a format specifier, which can be I (identifier), D (dotted name), or s
  (string)
* Alternatively, %% expands to a literal %, as usual.

For each such escape, the JSON object is searched using the element name
as key.  For identifiers, the element is expected to be a string, and
will be quoted per identifier quoting rules.  Dotted-names are used to
format possibly-qualified relation names and such; the element must be
an object with one, two or three string elements, each of which is
quoted per identifier rules, and output separated by periods.

Finally, for arrays we expand each element in the JSON array element,
and separate them with the separator specified in the {} part of the
format specifier.

For instance,
alvherre=# select format(json '{"fmt":"hello, %{who}s! This is %{name}I", "who":"world", "name":"a function"}');
               format
------------------------------------------
 hello, world! This is "a function"

Elements can be objects, in which case they are expanded recursively: a
"fmt" element is looked up and expanded as described above.


I don't yet see a need for %L escapes (that is, literals that can expand
to a single-quoted value or to NULL), but if I see it I will add that
too.

I am not against to this idea, although I don't see a strong benefit. . Just special function can be better - it has minimal relation to variadic "function" format - and nested mixed format can be messy
 

--
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: [PATCH] Negative Transition Aggregate Functions (WIP)
Next
From: Tatsuo Ishii
Date:
Subject: Re: Proposal: variant of regclass