Re: Add CREATE support to event triggers
От | Tom Lane |
---|---|
Тема | Re: Add CREATE support to event triggers |
Дата | |
Msg-id | 8650.1390508454@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Add CREATE support to event triggers (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Список | 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 по дате отправления: