Re: Add LINE: hint when schemaname.typename is a non-existent schema

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Jeevan Chalke <jeevan(dot)chalke(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Add LINE: hint when schemaname.typename is a non-existent schema
Date: 2015-03-18 18:04:17
Message-ID: 20150318180417.GX3636@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jeevan,

Thanks for the review.

Jeevan Chalke wrote:

> I think, there are few open questions here and thus marking it back to "Waiting on Author".
>
> Please have your views on the review comments already posted.
> Also make changes as Tom suggested about placing pstate at the beginning.

Pushed with that one change.

> postgres=# create or replace function
> f1(a abc.test.id%type) returns int as
> $$ select 1; $$
> language sql;
> ERROR: schema "abc" does not exist
>
> Is that expected?

We can leave this for a future patch.

> 2.
> Also what about pushing setup_parser_errposition_callback() inside func_get_detail() as well, just to limit it for namespace lookup?

Seemed messy enough that I left this as-is; and as Tom said elsewhere, I
think it's okay to have cursor position in other errors too. At the
very least, the user will know for certain what's the function being
processed that caused whatever failure.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Fabrízio de Royes Mello 2015-03-18 18:09:55 Re: Can pg_dump make use of CURRENT/SESSION_USER
Previous Message Tom Lane 2015-03-18 18:01:41 Re: Rethinking the parameter access hooks for plpgsql's benefit