Hi Neil,

> Looking at how to implement this, there is some rather dodgy code in
> warnAutoRange() in parse_relation.c that only emits the notice about
> adding a missing FROM clause entry if the query already has at least
> one
> range table entry in its FROM clause. The idea appears to be to not
> issue warnings about queries like "SELECT foo.*;", but it also means
> we
> don't end up warning about DELETE and UPDATE.
>
> I think the right fix is to remove the "inFromCl" check, and always
> issue a notice. With add_missing_from=true, all these queries are
> rejected anyway, so I think it makes sense to warn about all of them
> when add_missing_from is disabled. Objections?
>
No. That's why I'm thinking now while looking at the code Could you
provide a patch?


Euler Taveira de Oliveira
euler[at]yahoo_com_br





Yahoo! Acesso Grátis - Internet rápida e grátis.
Instale o discador agora! http://br.acesso.yahoo.com/

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Euler Taveira de Oliveira wrote:
> Could you provide a patch?

Sure, a revised patch is attached. Note that this change will also
require updating 25 (!) of the regression tests, since they use the
SELECT-without-FROM syntax. I will update the tests (by adding an
explicit FROM clause) before applying the patch -- which I'll do
tomorrow, barring any objections.

-Neil


---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Neil Conway wrote:
> Euler Taveira de Oliveira wrote:
> > Could you provide a patch?
>
> Sure, a revised patch is attached. Note that this change will also
> require updating 25 (!) of the regression tests, since they use the
> SELECT-without-FROM syntax. I will update the tests (by adding an
> explicit FROM clause) before applying the patch -- which I'll do
> tomorrow, barring any objections.

I just checked current CVS and see exactly what you describe:

test=> SELECT pg_class.* LIMIT 0;
ERROR: missing FROM-clause entry for table "pg_class"

test=> SET add_missing_from=true;
SET
test=> SELECT pg_class.* LIMIT 0;
NOTICE: adding missing FROM-clause entry for table "pg_class"

Is this what we want? I don't think so. I thought we wanted to
maintain the backward-compatible syntax of no FROM clause.

--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Bruce Momjian wrote:
> Is this what we want? I don't think so. I thought we wanted to
> maintain the backward-compatible syntax of no FROM clause.

We do? Why?

It is just as noncompliant with the SQL spec as other variants of this
behavior. add_missing_from would *always* have rejected those queries,
so ISTM we have been discouraging this case for as long as
add_missing_from has existed. If we want to allow this syntax by
default, we will need to effectively redefine the meaning of
add_missing_from -- which is fine, I just didn't think anyone wanted that.

-Neil

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Bruce Momjian <pgman@candle.pha.pa.us> writes:
> test=> SELECT pg_class.* LIMIT 0;
> NOTICE: adding missing FROM-clause entry for table "pg_class"

> Is this what we want? I don't think so. I thought we wanted to
> maintain the backward-compatible syntax of no FROM clause.

Well, the discussion earlier in the week concluded that
add_missing_from=true should emit a notice in every case where
add_missing_from=false would fail. Do you want to argue against
that conclusion?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend