On Monday, July 28, 2025, jian he <jian.universal...@gmail.com> wrote:
> On Mon, Jul 28, 2025 at 6:47 PM Vik Fearing <v...@postgresfriends.org> > wrote: > > > > > adding these pg_cast entries seems tricky. > > select proname, prosrc, proformat from pg_proc where proformat; > > what do you think? > My first impression of this choice was not good. How about changing the specification for create type. Right now input functions must declare either 1 or 3 arguments. Let’s also allow for 2 and 4-argument functions where the 2nd or 4th is where the format is passed. If a data type input function lacks one of those signatures it is a runtime error if a format clause is attached to its cast expression. For output, we go from having zero input arguments to zero or one, with the same resolution behavior. Pass null for the format if the clause is missing or the cast is done via the :: operator, or any other context format is not able to be specified. The slight variation to this would be to specify these 2/4 and 1-arg functions as optional “format_in” and “format_out” optional properties (like typmod_in). The format-aware code can look for these which will end up having the full implementation while the current IO functions would simply stub out calls, passing null as the format. (Or maybe some variation that looks similar to typmod handling…which I haven’t looked at.) David J.
