Re: Weird behavior during CREATE EXTENSION

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Weird behavior during CREATE EXTENSION
Date: 2016-01-13 22:00:23
Message-ID: 435.1452722423@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> writes:
> On 1/12/16 5:00 PM, Tom Lane wrote:
>> Also, there's some technology in CREATE FUNCTION that deals with the fact
>> that we may be calling the parser on a string different from the original
>> user command, which might be worth borrowing here --- at least part of
>> the confusion is that it's evidently reporting a cursor position relative
>> to the extension script as though it applied to the CREATE EXTENSION.

> Are you talking about plpgsql_compile_error_callback()? It looks like it
> does it's magic by relying on the plpgsql parser to keep track of where
> it's at.

Not really. It's about transposing the error to an "internal query"
instead of reporting it against the user's text.

I was imagining something roughly like the attached. Experimenting with
this, the good news is that you get a decent error position:

regression=# create extension pg_trgm ;
ERROR: syntax error at or near "USINGgist"
LINE 129: ALTER OPERATOR FAMILY gist_trgm_ops USINGgist ADD
^
QUERY: /* contrib/pg_trgm/pg_trgm--1.2.sql */

-- complain if script is sourced in psql, rather than via CREATE EXTENSION
...
ALTER OPERATOR FAMILY gin_trgm_ops USING gin ADD
FUNCTION 6 (text,text) gin_trgm_triconsistent (internal, int2, text, int4, internal, internal, internal);

CONTEXT: extension script file "/home/postgres/testversion/share/extension/pg_trgm--1.2.sql"
regression=#

The bad news is that psql regurgitates the whole script in the QUERY
field, because that's what we said was the internal query.

There are various ways you could imagine printing just part of the script;
for instance, starting from the cursor position, scan forward and back for
semicolons at line ends, and trim the query string to report just that
much. Or maybe it's worth teaching the grammar to report the first token
location of each parsetree, and then the loop in execute_sql_string could
stash that away for use by the error reporter.

I don't really have time to fool with this, but if someone else wants
to run with it ...

regards, tom lane

Attachment Content-Type Size
extension-error-location.patch text/x-diff 2.4 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Joshua D. Drake 2016-01-13 22:02:36 PgConf.US Hackers Track CFP
Previous Message Tom Lane 2016-01-13 20:37:01 Re: Fuzzy substring searching with the pg_trgm extension