Alvaro Herrera <alvhe...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
