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

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Daniel Gustafsson <daniel(at)yesql(dot)se>
Cc: Quan Zongliang <quanzongliang(at)yeah(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PL/pgSQL: Incomplete item Allow handling of %TYPE arrays, e.g. tab.col%TYPE[]
Date: 2023-10-16 12:05:57
Message-ID: CAFj8pRBhokukUnmJ6b5VEvKBa6ezs+aiHtXZRpMzoByseTK_eA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

po 16. 10. 2023 v 13:56 odesílatel Daniel Gustafsson <daniel(at)yesql(dot)se>
napsal:

> > On 16 Oct 2023, at 12:15, Quan Zongliang <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?
>

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.

> --
> Daniel Gustafsson
>
>
>
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nikita Malakhov 2023-10-16 12:10:16 Re: Pro et contra of preserving pg_proc oids during pg_upgrade
Previous Message Daniel Gustafsson 2023-10-16 11:53:11 Re: PL/pgSQL: Incomplete item Allow handling of %TYPE arrays, e.g. tab.col%TYPE[]