Re: improve CREATE EXTENSION error message

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Daniel Gustafsson <daniel(at)yesql(dot)se>
Cc: "Bossart, Nathan" <bossartn(at)amazon(dot)com>, Chapman Flack <chap(at)anastigmatix(dot)net>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: improve CREATE EXTENSION error message
Date: 2021-11-29 22:03:22
Message-ID: 1482885.1638223402@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Daniel Gustafsson <daniel(at)yesql(dot)se> writes:
>> On 29 Nov 2021, at 22:47, Bossart, Nathan <bossartn(at)amazon(dot)com> wrote:
>> On 11/29/21, 1:38 PM, "Chapman Flack" <chap(at)anastigmatix(dot)net> wrote:
>>> Maybe a larger break with the "This means the extension something something"
>>> formulation, and more on the lines of
>>> HINT: an extension must first be present (for example, installed with a
>>> package manager) on the system where PostgreSQL is running.

>> I like this idea. I can do it this way in the next revision if others
>> agree.

> I think taking it in this direction has merits.

I think "The extension must ..." would read better, otherwise +1.

I don't especially like intertwining the hint choice with the existing
special case for per-version files. Our usual style for conditional
hints can be found in places like sysv_shmem.c, and following that
would lead to a patch roughly like

if ((file = AllocateFile(filename, "r")) == NULL)
{
+ int ext_errno = errno;
+
if (version && errno == ENOENT)
{
/* no auxiliary file for this version */
pfree(filename);
return;
}
ereport(ERROR,
(errcode_for_file_access(),
errmsg("could not open extension control file \"%s\": %m",
- filename)));
+ filename),
+ (ext_errno == ENOENT) ? errhint("...") : 0));
}

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bossart, Nathan 2021-11-29 22:13:02 Re: improve CREATE EXTENSION error message
Previous Message Guillaume Lelarge 2021-11-29 21:49:30 Re: Lots of memory allocated when reassigning Large Objects