From: | Sean Chittenden <sean(at)chittenden(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Improved error message for CREATE EXTENSION patch... |
Date: | 2013-06-04 20:23:21 |
Message-ID: | FAA5F039-AE85-429B-90C1-F13CBEC1B39A@chittenden.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>>> "ERROR: XX000: no schemas in search_path are available for CREATE EXTENSION"
>
> Hm, I'm not sure that's much better than the existing wording. The
> bigger point here though is that if we consider this to be a user-facing
> error case, it ought to be ereport not elog.
>
> I checked what you get for the normal non-extension case:
>
> regression=# set search_path = bogus;
> SET
> regression=# create table t1 (f1 int);
> ERROR: no schema has been selected to create in
> regression=# \set VERBOSITY verbose
> regression=# create table t1 (f1 int);
> ERROR: 3F000: no schema has been selected to create in
> LOCATION: RangeVarGetCreationNamespace, namespace.c:485
>
> Seems like we ought to use the same message (and SQLSTATE) as in
> namespace.c, since nobody's complained about that one.
Sounds good to me and is clear enough that it would unblock me w/o having to resort to the source tree. -sc
--
Sean Chittenden
sean(at)chittenden(dot)org
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2013-06-04 20:24:07 | Re: Configurable location for extension .control files |
Previous Message | Andres Freund | 2013-06-04 20:20:11 | Re: Configurable location for extension .control files |