Michael Paquier wrote: > > As far as format_type_extended() is concerned, IMO we've gone far enough > > with the number of variants of format_type(). Making the function > > public makes sense to me, but let's add a bits32 flags argument instead > > of exposing the messy set of booleans. We can add compatibility > > wrappers for the flag combinations most used in core code, and maybe > > take the opportunity phase out the uncommon ones. > > OK, I was a bit hesitant to propose that without more input, so I > definitely agree with this API interface. I have tackled that in 0003, > with the following changes: > - let's get rid of format_type_with_typemod_qualified. This is only > used by postgres_fdw in one place. > - format_type_be_qualified is also rather localized, but I have kept > it. Perhaps this could be nuked as well. Input is welcome. > - let's keep format_type_be and format_type_with_typemod. Those are > largely more spread in the core code, so I don't think that we need to > invade things more than necessary.
Pushed 0003. Maybe we can get rid of format_type_be_qualified too, but I didn't care too much about it either; it's not a big deal I think. What interested me more was whether we could get rid of the FORMAT_TYPE_TYPEMOD_GIVEN flag, but ended up deciding not to pursue that as a phenomenal waste of time. Here are some references in case you care. https://www.postgresql.org/message-id/flat/200111101659.fAAGxKX06044%40postgresql.org https://git.postgresql.org/pg/commitdiff/a585c20d12d0e22befc8308e9f8ccb6f54a5df69 Thanks -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
