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 ]
[
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,
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
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.
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 ]
[ WHE
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
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 fo
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
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 an
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
co
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
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'
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 fir
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 a
* 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 R
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 time.
I don't see how th
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 b
* 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
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
magi
On Sat, 2004-10-23 at 07:35, Philip Hofstetter wrote:
> 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 po
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 easie
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
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: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
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 o
25 matches
Mail list logo
