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

From David E. Wheeler
Subject Re: Patch: Add parse_type Function
Date
Msg-id 3ED9B785-79CC-4356-A230-A6DBA822931D@justatheory.com
Whole thread Raw
In response to Re: Patch: Add parse_type Function  (Erik Wienhold <ewie@ewie.name>)
Responses Re: Patch: Add parse_type Function
List pgsql-hackers
On Feb 18, 2024, at 15:55, Erik Wienhold <ewie@ewie.name> wrote:

>> The overhead of parse_type_and_format can be related to higher planning
>> time. PL/pgSQL can assign composite without usage FROM clause.
>
> Thanks, didn't know that this makes a difference.  In that case both
> variants are on par.

Presumably this is a side-effect of the use of a RECORD here, which requires a FROM clause in pure SQL, yes?

The only way I can think of to avoid that is to:

1. Add a to_regtypmod() for those who just want the typemod.

2. Add a format_type_string() function that returns a string, the equivalent of this function but in C:

CREATE FUNCTION format_type_string(text) RETURNS TEXT AS $$
   SELECT format_type(to_regtype($1), to_regtypmod($1))
$$;

We could also keep the record-returning function for users who want both the regtype and the regytypemod at once, but
withthe other two I consider it less essential. 

Thoughts?

Best,

David




pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: JIT compilation per plan node
Next
From: Jelte Fennema-Nio
Date:
Subject: Re: Avoid switching between system-user and system-username in the doc