Re: Add RESPECT/IGNORE NULLS and FROM FIRST/LAST options

From: Tatsuo Ishii <ishii(at)postgresql(dot)org>
To: alvherre(at)kurilemu(dot)de
Cc: li(dot)evan(dot)chao(at)gmail(dot)com, tgl(at)sss(dot)pgh(dot)pa(dot)us, pramsey(at)cleverelephant(dot)ca, ojford(at)gmail(dot)com, peter(at)eisentraut(dot)org, krasiyan(at)gmail(dot)com, vik(at)postgresfriends(dot)org, andrew(at)tao11(dot)riddles(dot)org(dot)uk, david(at)fetter(dot)org, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Add RESPECT/IGNORE NULLS and FROM FIRST/LAST options
Date: 2025-10-14 00:01:00
Message-ID: 20251014.090100.1456332709714986500.ishii@postgresql.org
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> Hmm, this change made me realize that all or almost all the calls to
> get_func_name() would crash if it were to return a NULL value. I found
> no caller that checks the return value for nullness. I wonder why do we
> allow it to return NULL at all ... it might be better to just
> elog(ERROR) if the cache entry is not found.

I agree it's better but what about user defined functions? Some of
them might already check the return value to emit their own error
messages, I don't know. If so, modifying get_func_name() could break
them. Maybe invent something like get_func_name_with_error(calling
elog(ERROR)) and gradually update our code?

Best regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Chao Li 2025-10-14 00:09:56 Re: [PING] [PATCH v2] parallel pg_restore: avoid disk seeks when jumping short distance forward
Previous Message Chao Li 2025-10-13 23:52:58 Re: Fixed a typo in comment in compress_lz4.c