Bruce Momjian 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 t
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,
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
>
Neil Conway wrote:
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've applied the attached patch to HEAD. Due to the widespread updates
to the regression tests, the tests for some
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 applyi
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 n
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, wh
Neil Conway <[EMAIL PROTECTED]> writes:
> Well, my previous message described why I'm not sure that this line of
> reasoning is correct. I think the only really proper configuration is
> add_missing_from=false and an explicit USING/FROM list. Just about the
> only reason to enable add_missing_fr
Tom Lane wrote:
... but when it is TRUE, there should be a notice, same as there is in
SELECT. UPDATE should produce such a notice too, IMHO. Probably we
omitted the message originally because there was no way to avoid it
in a DELETE, but now there will be.
Well, my previous message described why
Neil Conway <[EMAIL PROTECTED]> writes:
> Euler Taveira de Oliveira wrote:
>> euler=# delete from t1 where t1.a = t3.x;
>> DELETE 1
>> euler=#
>>
>> I think we need at least a NOTICE here. Of course it could be extended
>> to UPDATE too.
> I can see an argument for having a NOTICE here. On the o
Euler Taveira de Oliveira wrote:
I'm worried about add_missing_from enabled.
The plan is to make add_missing_from default to false in 8.1
euler=# delete from t3 using t1 where b > 500;
DELETE 4
euler=# select * from t3;
x | y
---+---
(0 rows)
In this case, I 'forget' to do the join and it delete
Hi Neil,
> > BTW, this patch is lacking ruleutils.c support. Put a DELETE USING
> > into a rule and see whether pg_dump will dump the rule correctly
> ...
>
> Good catch; a revised patch is attached.
>
Greate job. But I'm worried about add_missing_from enabled. See:
euler=# delete from t3 usi
[ CC'ing hackers to see if anyone else wants to weigh in ]
Tom Lane wrote:
Of course, the entire reason this didn't happen years ago is that we
couldn't agree on what keyword to use... you sure you want to reopen
that discussion?
Sure, it doesn't seem too difficult to settle to me.
I don't think ch
Tom Lane wrote:
BTW, this patch is lacking ruleutils.c support. Put a DELETE USING
into a rule and see whether pg_dump will dump the rule correctly ...
Good catch; a revised patch is attached.
-Neil
Index: doc/src/sgml/ref/delete.sgml
===
BTW, this patch is lacking ruleutils.c support. Put a DELETE USING
into a rule and see whether pg_dump will dump the rule correctly ...
regards, tom lane
---(end of broadcast)---
TIP 6: Have you searched our list archives?
Neil Conway <[EMAIL PROTECTED]> writes:
> On a related note, UPDATE uses the FROM keyword to denote the list of
> relations to join with, whereas DELETE uses USING. Should we make USING
> an alias for FROM in UPDATE and if so, should we deprecate FROM? This
> would be more consistent, which I su
16 matches
Mail list logo
