Re: Add CREATE support to event triggers

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Add CREATE support to event triggers
Date: 2014-01-14 08:08:30
Message-ID: CAFj8pRC6s3=b2T+3=2EC8N9CXSW8V7Q7c6V3g_2b3F=Z6dGTLw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello

2014/1/13 Alvaro Herrera <alvherre(at)2ndquadrant(dot)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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hannu Krosing 2014-01-14 08:08:40 Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance
Previous Message Amit Kapila 2014-01-14 07:39:07 Re: [PATCH] Doc fix for VACUUM FREEZE