Re: Add CREATE support to event triggers

On Thu, Mar 13, 2014 at 5:06 PM, Alvaro Herrera
<alvherre(at)2ndquadrant(dot)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 reasonable standalone
>> because CREATE TABLE uses it internally.
>
> I have been hacking on this on and off. This afternoon I discovered
> that interval typmod output can also be pretty unusual. Example:
>
> create table a (a interval year to month);
>
> For the column, we get this type spec (note the typmod):
>
> "coltype": {
> "is_array": false,
> "schemaname": "pg_catalog",
> "typename": "interval",
> "typmod": " year to month"
> },
>
> so the whole command output ends up being this:
>
> NOTICE: expanded: CREATE TABLE public.a (a pg_catalog."interval" year to month ) WITH (oids=OFF)
>
> However, this is not accepted on input:
>
> alvherre=# CREATE TABLE public.a (a pg_catalog."interval" year to month ) WITH (oids=OFF);
> ERROR: syntax error at or near "year"
> LÍNEA 1: CREATE TABLE public.a (a pg_catalog."interval" year to mon...
> ^
>
> I'm not too sure what to do about this yet. I checked the catalogs and
> gram.y, and it seems that interval is the only type that allows such
> strange games to be played. I would hate to be forced to add a kludge
> specific to type interval, but that seems to be the only option. (This
> would involve checking the OID of the type in deparse_utility.c, and if
> it's INTERVALOID, then omit the schema qualification and quoting on the
> type name).
>
> I have also been working on adding ALTER TABLE support. So far it's
> pretty simple; here is an example. Note I run a single command which
> includes a SERIAL column, and on output I get three commands (just like
> a serial column on create table).
>
> alvherre=# alter table tt add column b numeric, add column c serial, alter column a set default extract(epoch from now());
> NOTICE: JSON blob: {
> "definition": [
> {
> "clause": "cache",
> "fmt": "CACHE %{value}s",
> "value": "1"
> },
> {
> "clause": "cycle",
> "fmt": "%{no}s CYCLE",
> "no": "NO"
> },
> {
> "clause": "increment_by",
> "fmt": "INCREMENT BY %{value}s",
> "value": "1"
> },
> {
> "clause": "minvalue",
> "fmt": "MINVALUE %{value}s",
> "value": "1"
> },
> {
> "clause": "maxvalue",
> "fmt": "MAXVALUE %{value}s",
> "value": "9223372036854775807"
> },
> {
> "clause": "start",
> "fmt": "START WITH %{value}s",
> "value": "1"
> },
> {
> "clause": "restart",
> "fmt": "RESTART %{value}s",
> "value": "1"
> }
> ],
> "fmt": "CREATE %{persistence}s SEQUENCE %{identity}D %{definition: }s",
> "identity": {
> "objname": "tt_c_seq",
> "schemaname": "public"
> },
> "persistence": ""
> }

What does the colon-space in %{definition: }s mean?

In general, it seems like you're making good progress here, and I'm
definitely happier with this than with previous approaches, but I'm
still concerned about how maintainable it's going to be.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company