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(at)yeah(dot)net
> <mailto:quanzongliang(at)yeah(dot)net>> napsal:
>
>
>
> On 2023/10/16 20:05, Pavel Stehule wrote:
> >
> >
> > po 16. 10. 2023 v 13:56 odesílatel Daniel Gustafsson
> <daniel(at)yesql(dot)se <mailto:daniel(at)yesql(dot)se>
> > <mailto:daniel(at)yesql(dot)se <mailto:daniel(at)yesql(dot)se>>> napsal:
> >
> >      > On 16 Oct 2023, at 12:15, Quan Zongliang
> <quanzongliang(at)yeah(dot)net <mailto:quanzongliang(at)yeah(dot)net>
> >     <mailto:quanzongliang(at)yeah(dot)net
> <mailto:quanzongliang(at)yeah(dot)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
> >
> >
> >
>