Re: DELETE ... USING

From: Neil Conway <neilc(at)samurai(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Euler Taveira de Oliveira <eulerto(at)yahoo(dot)com(dot)br>, PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: DELETE ... USING
Date: 2005-04-06 07:08:30
Message-ID: 42538AEE.4040704@samurai.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Tom Lane wrote:
> Hmm. There's some merit in that position, but consider this: we are
> encouraging people rather strongly to move to the add_missing_from=false
> behavior. So add_missing_from=true could be seen as a testing situation
> in which you'd like to know which of your queries have a problem, while
> not actually causing your app to fail. Strict backwards compatibility
> won't produce the warning but also won't help you find what will break.

Hmm, ok, I can see where that would be useful.

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?

-Neil

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dave Page 2005-04-06 09:27:04 8.0.2 beta announcement??
Previous Message Joshua D. Drake 2005-04-05 23:34:45 Re: REINDEX ALL

Browse pgsql-patches by date

  From Date Subject
Next Message Neil Conway 2005-04-06 08:26:36 Re: avg(int2) and avg(int8) micro-opt
Previous Message Neil Conway 2005-04-06 05:24:27 Re: Have psql \dD show checks