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

From David E. Wheeler
Subject Re: Patch: Add parse_type Function
Date
Msg-id 715521D7-4BE4-4075-96E8-D0190818AB10@justatheory.com
Whole thread Raw
In response to Re: Patch: Add parse_type Function  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Patch: Add parse_type Function
List pgsql-hackers
On Feb 19, 2024, at 15:47, Tom Lane <tgl@sss.pgh.pa.us> wrote:

>> 1. Add a to_regtypmod() for those who just want the typemod.
>
> Seems like there's a good case for doing that.

I’ll work on that.

> I'm less thrilled about that, mainly because I can't think of
> a good name for it ("format_type_string" is certainly not that).
> Is the use-case for this functionality really strong enough that
> we need to provide it as a single function rather than something
> assembled out of spare parts?

Not essential for pgTAP, no, as we can just use the parts. It was the typmod bit that was missing.

On Feb 19, 2024, at 17:13, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> After some time ruminating, a couple of possibilities occurred to
> me:
> reformat_type(text)
> canonical_type_name(text)

I was just thinking about hitting the thesaurus entry for “canonical”, but I quite like reformat_type. It’s super clear
anddraws the parallel to format_type() more clearly. Will likely steal the name for pgTAP if we don’t add it to core.
:-)

> I'm still unconvinced about that, though.

I guess the questions are:

* What are the other use cases for it?
* How obvious is it how to do it?

For the latter, it could easily be an example in the docs.

Best,

David




pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Add last_commit_lsn to pg_stat_database
Next
From: Michael Paquier
Date:
Subject: Re: Possible to trigger autovacuum?