Re: Bug or stupidity - Mailing list pgsql-general

Stephan,

>>Perhaps the 8.0 would be a perfect time since it's a change of the major
>>number.
>>
>>
>
>Maybe, but I think it'll be a hard sell without a replacement for the
>delete form that works when it's off.
>
>
I'm not sure I understand this. Apparently you want tables to be added
to the FROM clause of a DELETE statement. Why? If you have more than one
table listed in the FROM clause, how do you know which one that is
subject to DELETE? Surely you're not suggesting that the DELETE should
affect more than one table?

If the WHERE clause that defines the criteria for deletion involves more
than one table, then you'd use a sub select and that has a FROM clause
of its own.

Can you give me an example on what you mean?

>> > In addition, until we have a form of delete which allows a "from"
>> > list, there are some queries which are really more naturally written
>> > in a form similar to add_missing_from
>> > (although "from" lists would be better).
>> >
>>Still, if the query is incorrect, I want to know about it. I don't ever
>>
>>
>
>But, is the query incorrect?  It does what PostgreSQL says it will.
>That's not what the spec says it'll do, but the same is true of most of
>the extensions, and I don't think people generally consider queries using
>those as incorrect.
>
>
I haven't seen any other extension that, when enabled, attempts to
"improve" badly written SQL in a way that potentially gives incorrect
query results. As I said in another post, this is like having a compiler
that instead of complaining about a misspelled variable, adds a new one.

I can give you an example why I think this option is bad:
Assume that you work with some client software. You write your queries
and you test your system. You see some notifications passing by from the
server (perhaps) but you don't pay much attention to them. You get
notifications all the time for other reasons. Nothing to worry about. In
fact, your test system is written to trigger on errors and warnings and
ignore notifications.

So all your tests run fine. You ship to your customers. The customers
starts adding data to tables and finds some strange behavior. It turns
out that everything is caused by tables being added to the FROM clause.
You didn't see the problem in your test because there, the added table
had less than 2 tuples in it.

As I said before, I don't object to the presence of this "option" so
that people that really knows _why_ they enable it can do so, but I
strongly object to having this option enabled by default. I suggest that:

1. Have this option disabled by default.
2. Print WARNING's rather than notifications when tables are added.

Regards,
Thomas Hallgren