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