Re: PL/pgSQL: Incomplete item Allow handling of %TYPE arrays, e.g. tab.col%TYPE[]

On 2023/10/17 12:15, Pavel Stehule wrote:
> 
> 
> út 17. 10. 2023 v 3:30 odesílatel Quan Zongliang <quanzongliang@yeah.net 
> <mailto:quanzongliang@yeah.net>> napsal:
> 
> 
> 
>     On 2023/10/16 20:05, Pavel Stehule wrote:
>      >
>      >
>      > po 16. 10. 2023 v 13:56 odesílatel Daniel Gustafsson
>     <daniel@yesql.se <mailto:daniel@yesql.se>
>      > <mailto:daniel@yesql.se <mailto:daniel@yesql.se>>> napsal:
>      >
>      >      > On 16 Oct 2023, at 12:15, Quan Zongliang
>     <quanzongliang@yeah.net <mailto:quanzongliang@yeah.net>
>      >     <mailto:quanzongliang@yeah.net
>     <mailto:quanzongliang@yeah.net>>> wrote:
>      >
>      >      > Implement TODO item:
>      >      > PL/pgSQL
>      >      > Incomplete item Allow handling of %TYPE arrays, e.g.
>     tab.col%TYPE[]
>      >
>      >     Cool!  While I haven't looked at the patch yet, I've wanted this
>      >     myself many
>      >     times in the past when working with large plpgsql codebases.
>      >
>      >      > As a first step, deal only with [], such as
>      >      > xxx.yyy%TYPE[]
>      >      > xxx%TYPE[]
>      >      >
>      >      > It can be extended to support multi-dimensional and complex
>      >     syntax in the future.
>      >
>      >     Was this omitted due to complexity of implementation or for some
>      >     other reason?
>      >
>     Because of complexity.
> 
>      >
>      > There is no reason for describing enhancement. The size and
>     dimensions
>      > of postgresql arrays are dynamic, depends on the value, not on
>      > declaration. Now, this information is ignored, and can be
>     compatibility
>      > break to check and enforce this info.
>      >
>     Yes. I don't think it's necessary.
>     If anyone needs it, we can continue to enhance it in the future.
> 
> 
> I don't think it is possible to do it.  But there is another missing 
> functionality, if I remember well. There is no possibility to declare 
> variables for elements of array.
The way it's done now is more like laziness.

Is it possible to do that?
If the parser encounters %TYPE[][]. It can be parsed. Then let 
parse_datatype do the rest.

For example, partitioned_table.a%TYPE[][100][]. Parse the type 
name(int4) of partitioned_table.a%TYPE and add the following [][100][]. 
Passing "int4[][100][]" to parse_datatype will give us the array 
definition we want.

Isn't this code a little ugly?

> 
> I propose syntax xxx.yyy%ELEMENTTYPE and xxx%ELEMENTTYPE
> 
> What do you think about it?
No other relational database can be found with such an implementation. 
But it seems like a good idea. It can bring more convenience to write 
stored procedure.

> 
> Regards
> 
> Pavel
> 
> 
>      >
>      >     --
>      >     Daniel Gustafsson
>      >
>      >
>      >
>