Re: Patch: Add parse_type Function - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Patch: Add parse_type Function
Date
Msg-id 2245610.1707760389@sss.pgh.pa.us
Whole thread Raw
In response to Re: Patch: Add parse_type Function  ("David E. Wheeler" <david@justatheory.com>)
Responses Re: Patch: Add parse_type Function
Re: Patch: Add parse_type Function
List pgsql-hackers
"David E. Wheeler" <david@justatheory.com> writes:
> [ v4-0001-Add-parse_type-SQL-function.patch ]

It strikes me that this is basically to_regtype() with the additional
option to return the typmod.  That leads to some questions:

* Should we choose a name related to to_regtype?  I don't have any
immediate suggestions, but since you didn't seem entirely set on
parse_type, maybe it's worth thinking along those lines.  OTOH,
to the extent that people would use this with format_type, maybe
parse_type is fine.

* Perhaps the type OID output argument should be declared regtype
not plain OID?  It wouldn't make any difference for passing it to
format_type, but in other use-cases perhaps regtype would be more
readable.  It's not a deal-breaker either way of course, since
you can cast oid to regtype or vice versa.

* Maybe the code should be in adt/regproc.c not format_type.c.

* Experience with to_regtype suggests strongly that people would
prefer "return NULL" to failure for an unrecognized type name.


Skimming the patch, I notice that the manual addition to
builtins.h should be unnecessary: the pg_proc.dat entry
should be enough to create an extern in fmgrprotos.h.
Also, I'm pretty sure that reformat_dat_file.pl will
think your pg_proc.dat entry is overly verbose.  See
https://www.postgresql.org/docs/devel/system-catalog-initial-data.html

            regards, tom lane



pgsql-hackers by date:

Previous
From: "Tristan Partin"
Date:
Subject: Re: make dist using git archive
Next
From: Matthias van de Meent
Date:
Subject: Re: Reducing output size of nodeToString