Here's the code that reproduces the behavior: http://paste.debian.net/1035412/
I have already discussed this in the IRC channel but there doesn't seem to be a consensus on whether this is a bug here's a brief transcript of RhodiumToad's opinion:
> this isn't new, goes back to 9.1 at least
> basically, the error path in sql_fn_post_column_ref is a bit confused.
> seeing r.c it tries to resolve it as parameter.field, fails, and rather than reporting the error directly as being a missing field, it just returns with the reference unresolved
>then the outer parser code, having failed to resolve it as table.column and having had the hook function not override it, reports it on the assumption that it's a missing table
> so it's probably been this way for as long as named parameters have worked in language sql
> msl09: as far as I can tell it's just giving the wrong error in an error path, everything that's supposed to work does work
I have already discussed this in the IRC channel but there doesn't seem to be a consensus on whether this is a bug here's a brief transcript of RhodiumToad's opinion:
> this isn't new, goes back to 9.1 at least
> basically, the error path in sql_fn_post_column_ref is a bit confused.
> seeing r.c it tries to resolve it as parameter.field, fails, and rather than reporting the error directly as being a missing field, it just returns with the reference unresolved
>then the outer parser code, having failed to resolve it as table.column and having had the hook function not override it, reports it on the assumption that it's a missing table
> so it's probably been this way for as long as named parameters have worked in language sql
> msl09: as far as I can tell it's just giving the wrong error in an error path, everything that's supposed to work does work
> msl09: but the error is definitely misleading
My question is "Is this a bug? Should it be reported?"
