Re: [HACKERS] Re: Join/table alias bug
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Re: Join/table alias bug |
Дата | |
Msg-id | 2021.956241653@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Join/table alias bug (Peter Eisentraut <e99re41@DoCS.UU.SE>) |
Ответы |
Re: [HACKERS] Re: Join/table alias bug
Re: [HACKERS] Re: Join/table alias bug |
Список | pgsql-bugs |
Peter Eisentraut <e99re41@DoCS.UU.SE> writes: > ... The reason this behaves that way is because queries > without from lists (SELECT my_tbl.a) are valid in PostgreSQL for > historical reasons, so we're stuck with it. Not only for historical reasons: there are cases where it allows you to do things you couldn't easily do otherwise. An example is deleting using a join: DELETE FROM target WHERE field1 = source.field2 which deletes any record in target whose field1 matches any field2 value in source. This isn't SQL92 since DELETE doesn't allow you to specify any tables except the target table in FROM. (Yeah, I know this example could be written with a subselect --- but with a more complex WHERE condition it gets harder to do that. Also slower.) > We've pondered many times about emitting warnings but a definite > consensus was never reached. Bruce had actually put in some code to emit warnings, but Thomas objected to it for reasons I don't recall clearly. I think it was an implementation issue rather than objecting to the idea of having warnings. AFAIR we had pretty much agreed that a warning would be a good idea. IIRC, Bruce's code would emit a warning whenever an implicit RTE was added. I think that might be overly verbose --- I'd be inclined to warn only in the case that an implicit RTE is added for a table that has an RTE already (under a different alias). That is the only situation I've seen user complaints about. regards, tom lane
В списке pgsql-bugs по дате отправления: