On Tue, Feb 3, 2015 at 11:10 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Ryan Kelly <rpkell...@gmail.com> writes: >> The attached patch adds a LINE: ... hint when schemaname.typename >> results in a schema which does not exist. I came across this when a >> missing comma in a SELECT list resulted in an error without a location >> in a query a few thousand lines long. > > I think this is a good problem to attack, but the proposed patch seems > a bit narrow and brute-force. Surely this isn't the only place where > we're missing an errposition pointer on a "no such schema" error?
I managed to find four code paths that failed to report an error position if the schema did not exist: - Schema-qualified types (e.g. select schemaname.typename 'foo') - Schema-qualified operators (e.g. select 1 operator(schemaname.+) 1) - Schema-qualified table names in CREATE TABLE (e.g. create table schemaname.tablename (colname integer)) - Schema-qualified function calls (e.g. select schemaname.funcname()) > It's probably not reasonable to add a pstate argument to > LookupExplicitNamespace itself, given that namespace.c isn't part > of the parser. But you could imagine adding an interface function > in the parser that calls LookupExplicitNamespace and then throws a > position-aware error on failure, and then making sure that all schema > lookups in the parser go through that. While searching for other instances of this problem, I found that using a schema that does not exist in conjunction with a collation reported the position. That code uses setup_parser_errposition_callback and the documentation for that function seems to indicate that the usage of it in my newly attached patch are consistent. I do not know, however, if this is the cleanest approach or if I should actually create a function like validate_explicit_namespace to handle this (and I'm also not sure where such a function should live, if I do create it). -Ryan Kelly
missing_type_schema_hint_v2.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
