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.
Pus
Jeevan Chalke wrote:
> Álvaro,
>
> 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.
For some reason I missed your previous email.
> Also make changes as Tom suggested about placing ps
Jeevan Chalke writes:
> I am more concerned about this:
> 1.
> 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?
Yes, or at least, if it's not what we want it's not this patch
Álvaro,
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.
I am more concerned about this:
1.
postgres=# create or re
Alvaro Herrera writes:
> Agreed; the attached patch does it that way. (I notice that we have the
> pstate as first arg in many places; I put at the end for
> make_oper_cache_key, together with location. Is there some convention
> to have it as first arg?)
Yes, parser-related functions always ha
In the interest of moving forward, I have updated this patch because
Ryan has been inactive for over a month now.
Tom Lane wrote:
> Yeah, setup_parser_errposition_callback would work too. I'm not sure
> offhand which I like better. One thing to keep in mind is that the
> callback approach resul
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: tested, failed
Spec compliant: not tested
Documentation:not tested
Tom suggested few changes already which I too think author needs to addre
Ryan Kelly writes:
> On Tue, Feb 3, 2015 at 11:10 AM, Tom Lane wrote:
>> 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
On Tue, Feb 3, 2015 at 11:10 AM, Tom Lane wrote:
> Ryan Kelly 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
Ryan Kelly 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 prob
On Mon, Feb 2, 2015 at 2:44 PM, Ryan Kelly wrote:
> 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 lon
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.
Before:
(postgres@[local]:5432 14:41:25) [postgres]> s
12 matches
Mail list logo
