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

From Tom Lane
Subject Re: Add CREATE support to event triggers
Date
Msg-id 8650.1390508454@sss.pgh.pa.us
Whole thread Raw
In response to Re: Add CREATE support to event triggers  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
Alvaro Herrera <alvherre@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 reason why this can't be
> returned simply as pg_catalog.varchar(10); this should work fine on the
> receiving end as well, and give the same result.

I think people would be unhappy if we changed the output of, say, pg_dump
that way.  But it's presumably not a problem for strings inside event
triggers.  Once upon a time, the typmods would have been an issue, but now
that we support them in generic typename syntax I think we're good.

> The other cases I'm worried about are types like bit(1) vs. unadorned
> bit vs. double-quoted "bit", and "char", etc.  I'm not sure I'm dealing
> with them correctly right now.  So even if by the above paragraph I
> could make the is_system thingy go away, I might still need it to cover
> this case.

Yeah, there are some weird cases there.  I think you can make them go away
if you always print the fully qualified type name, ie don't omit
"pg_catalog", and use pg_type.typname not any converted version (and don't
forget to double-quote anything that might be a reserved word).
But I've not looked closely at the code.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Warning in new GIN code
Next
From: "Joshua D. Drake"
Date:
Subject: Why do we let autovacuum give up?