Martijn van Oosterhout wrote:
Sure, that's what you could do, but it makes the query rather more
complex than it needs to be.
Do you consider this overly complex? Compare:
DELETE FROM x WHERE EXISTS (SELECT * FROM table WHERE x.a = table.a and
x.b table.b and table.c = 4)
to:
DELETE FROM x,
Martijn,
I realize that the change I'm proposing might be too complex to be added
in the upcoming 8.0 release. I do find this discussion interesting
though, so please bear with me while I try to tie up some loose ends.
UPDATE [ ONLY ] table SET col = expression [, ...]
[ FROM fromlist ]
[
On Wed, Oct 27, 2004 at 12:15:10AM +0200, Thomas Hallgren wrote:
Martijn,
Do you have a better
suggestion, other than forbidding the currently allowed syntax?
Yes I do.
We agree that my second example should be disallowed since the semantics
of the FROM clause is different for a DELETE
I didn't see that join syntax in the documentation for delete, thanks
for pointing it out.
MS SQL Server syntax for a delete is a little less confusing, IMHO.
instead of DELETE FROM x WHERE x.a = table.a and x.b table.b and table.c = 4;
they have DELETE x FROM x join table on x.a = table.a and
Martijn,
I realize that the change I'm proposing might be too complex to be added
in the upcoming 8.0 release. I do find this discussion interesting
though, so please bear with me while I try to tie up some loose ends.
UPDATE [ ONLY ] table SET col = expression [, ...]
[ FROM fromlist ]
[
On Wed, Oct 27, 2004 at 22:10:05 +0200,
2. Let's change so that add_missing_from is disabled by default and
doesn't affect the DELETE statement at all.
That is supposed to happen. My memory was that 8.0 was the release that
the default was going to change, but if not then it should be 8.1.
I
Bruno Wolff III [EMAIL PROTECTED] writes:
On Wed, Oct 27, 2004 at 22:10:05 +0200,
2. Let's change so that add_missing_from is disabled by default and
doesn't affect the DELETE statement at all.
That is supposed to happen. My memory was that 8.0 was the release that
the default was going to
On Mon, 25 Oct 2004, Thomas Hallgren wrote:
Stephan,
In general, when we add a backwards compatibility option, we give
a couple of versions before the default is changed.
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
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
On Tue, Oct 26, 2004 at 05:25:57PM +0200, Thomas Hallgren wrote:
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.
Sure, that's what you could do, but it makes the query rather more
On Tue, Oct 26, 2004 at 06:21:23PM +0200, Thomas Hallgren wrote:
Do you consider this overly complex? Compare:
DELETE FROM x WHERE EXISTS (SELECT * FROM table WHERE x.a = table.a and
x.b table.b and table.c = 4)
to:
DELETE FROM x, table WHERE x.a = table.a and x.b table.b and table.c
Martijn,
Do you have a better
suggestion, other than forbidding the currently allowed syntax?
Yes I do.
We agree that my second example should be disallowed since the semantics
of the FROM clause is different for a DELETE so the add_missing_from
is actually not adding to a FROM clause, it is
Stephan Szabo wrote:
It's enabled in large part for backwards compatibility. There's a
runtime
option that controls the behavior (add_missing_from).
IMHO, it would be a more natural choice to have the add_missing_from
disabled by default. Why would anyone *ever* want faulty SQL being
* Thomas Hallgren [EMAIL PROTECTED] [2004-10-25 15:52:20 +0200]:
IMHO, it would be a more natural choice to have the add_missing_from
disabled by default. Why would anyone *ever* want faulty SQL being
magically patched up by the dbms?
That assumes that developers will implement queries in
On Mon, 25 Oct 2004, Thomas Hallgren wrote:
Stephan Szabo wrote:
It's enabled in large part for backwards compatibility. There's a
runtime
option that controls the behavior (add_missing_from).
IMHO, it would be a more natural choice to have the add_missing_from
disabled by default.
* Thomas Hallgren [EMAIL PROTECTED] [2004-10-25 19:06:40 +0200]:
I don't see how that makes a difference really.
/me notes the timestamp on his post and vows never to post before 8am
again.
--
Steven Klassen - Lead Programmer
Command Prompt, Inc. - http://www.commandprompt.com/
PostgreSQL
Stephan,
In general, when we add a backwards compatibility option, we give
a couple of versions before the default is changed.
Perhaps the 8.0 would be a perfect time since it's a change of the major
number.
In addition, until we have a form of delete which allows a from
list, there are
Thomas Hallgren wrote:
Steven,
That assumes that developers will implement queries in their code
without testing them. Unfortunately, that's probably not too far from
reality. I've thought of it as a nice debugging feature while I'm
trying to hammer out a complicated query for the first
On Sat, 2004-10-23 at 07:35, Philip Hofstetter wrote:
snip It would just have been easier to find if PostgreSQL actually had
told me so (I'm not getting those NOTICEs from PHP...).
As far as I can tell, Apache or PHP snarfs up all the messages that
postgres generates before they can get to the
Hello,
I think, I found a bug, but maybe it's just my stupidity. Granted: What
I did was an error on my part, but I still think, PostgreSQL should not
do what it does.
I've already created a simple testcase:
popscan_light= create table a (id serial, name varchar(10), primary
key(id)) without
On Sat, Oct 23, 2004 at 02:17:16PM +, Philip Hofstetter wrote:
Hello,
I think, I found a bug, but maybe it's just my stupidity. Granted: What
I did was an error on my part, but I still think, PostgreSQL should not
do what it does.
... snip ...
popscan_light= select aliasa.name,
Hi,
Martijn van Oosterhout wrote:
popscan_light= select aliasa.name, aliasb.name2 from a aliasa left join
b aliasb using (id) order by b.name2;
NOTICE: adding missing FROM-clause entry for table b
name | name2
---+---
gnegg | gnegglink
blepp | blepplink
gnegg | gnegglink
blepp |
On Sat, Oct 23, 2004 at 02:35:20PM +, Philip Hofstetter wrote:
As for what's SQL standard, I think by a strict definition your query
shouldn't be allowed at all, referencing an undefined table.
This is exactly what I think too. I mean: I know I made an error in my
query. It would just
On Sat, 23 Oct 2004, Philip Hofstetter wrote:
As for what's SQL standard, I think by a strict definition your query
shouldn't be allowed at all, referencing an undefined table.
This is exactly what I think too. I mean: I know I made an error in my
query. It would just have been easier to
24 matches
Mail list logo
