Re: BUG #18866: Running pg_freespace() on views triggers an Abort

From: "Euler Taveira" <euler(at)eulerto(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Tender Wang" <tndrwang(at)gmail(dot)com>, tharakan(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org, "Heikki Linnakangas" <hlinnaka(at)iki(dot)fi>
Subject: Re: BUG #18866: Running pg_freespace() on views triggers an Abort
Date: 2025-03-26 16:51:51
Message-ID: d8bce206-04fb-4503-b032-fe9e29b41459@app.fastmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Wed, Mar 26, 2025, at 1:00 PM, Tom Lane wrote:
> "Euler Taveira" <euler(at)eulerto(dot)com> writes:
> > Your patch needs some adjustments. There is no need to include pg_class.h. I
> > don't like the proposed error message. I prefer saying the relation cannot be
> > opened because that's what will happen if it reaches this code path.
>
> I don't care for that proposal either: we just did open the relation ;-)

Fair point.

> relcache.c:
> elog(ERROR, "relation \"%s\" does not have storage",
> RelationGetRelationName(relation));
>
> So the previous proposal was evidently modeled on the first two of
> these precedents. Personally I prefer messages that say *why*
> something failed, so I'd go with something more like "relation \"%s\"
> does not have storage". Use of errdetail_relkind_not_supported is
> fine though.

I thought about saying "no storage" but don't know why was convinced by that
proposal. Your suggestion works for me.

--
Euler Taveira
EDB https://www.enterprisedb.com/

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Álvaro Herrera 2025-03-26 17:33:42 Re: BUG #18866: Running pg_freespace() on views triggers an Abort
Previous Message Tomas Vondra 2025-03-26 16:09:34 Re: BUG #18855: Using BRIN index with int8_bloom_ops produces incorrect results