Re: Better error messages for %TYPE and %ROWTYPE in plpgsql

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Better error messages for %TYPE and %ROWTYPE in plpgsql
Date: 2024-02-26 20:10:08
Message-ID: CAFj8pRCxOPgdaY=x0P8YxMGSn-md6NFQe9b4RFegoNAh1fNDfQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

po 26. 2. 2024 v 21:02 odesílatel Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> napsal:

> Per recent discussion[1], plpgsql returns fairly unhelpful "syntax
> error" messages when a %TYPE or %ROWTYPE construct references a
> nonexistent object. Here's a quick little finger exercise to try
> to improve that.
>
> The basic point is that plpgsql_parse_wordtype and friends are
> designed to return NULL rather than failing (at least when it's
> easy to do so), but that leaves the caller without enough info
> to deliver a good error message. There is only one caller,
> and it has no use at all for this behavior, so let's just
> change those functions to throw appropriate errors. Amusingly,
> plpgsql_parse_wordrowtype was already behaving that way, and
> plpgsql_parse_cwordrowtype did so in more cases than not,
> so we didn't even have a consistent "return NULL" story.
>
> Along the way I got rid of plpgsql_parse_cwordtype's restriction
> on what relkinds can be referenced. I don't really see the
> point of that --- as long as the relation has the desired
> column, the column's type is surely well-defined.
>

+1

Pavel

> regards, tom lane
>
> [1]
> https://www.postgresql.org/message-id/flat/88b574f4-cc08-46c5-826b-020849e5a356%40gelassene-pferde.biz
>
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2024-02-26 20:14:56 Re: libpq: PQfnumber overload for not null-terminated strings
Previous Message Tom Lane 2024-02-26 20:02:20 Better error messages for %TYPE and %ROWTYPE in plpgsql