Re: BUG #7846: Documentation: Should FOUND be documented as an output of UPDATE statement?
От | Kevin Grittner |
---|---|
Тема | Re: BUG #7846: Documentation: Should FOUND be documented as an output of UPDATE statement? |
Дата | |
Msg-id | 1360011928.28724.YahooMailNeo@web162901.mail.bf1.yahoo.com обсуждение исходный текст |
Ответ на | BUG #7846: Documentation: Should FOUND be documented as an output of UPDATE statement? (mike@fontling.com) |
Список | pgsql-bugs |
"mike@fontling.com" <mike@fontling.com> wrote:=0A=0A> Documentation for the= SQL UPDATE statement doesn't mention that=0A> it sets the FOUND variable. = (Refer to sql-update.html,=0A> "Outputs".) That behavior *is* documented, b= ut only in=0A> plpgsql-statements.html (Basic Statements, section 39.5.5).= =0A>=0A> I understand the difference between a SQL statement and a=0A> PL/P= GSQL statement. But if I were looking for the effects and=0A> side-effects = of an UPDATE statement, I'd go to the docs for=0A> UPDATE, not for PL/PGSQL= basic statements. I think that's what=0A> most people would do, especially= if they didn't have prior=0A> knowledge of the FOUND variable.=0A=0AOutsid= e of plpgsql there isn't any FOUND variable to set.=A0 If we=0Adid what you= suggest, I think we'd get bug reports about this:=0A=0Atest=3D# update t s= et amt =3D 2 where id =3D 1;=0AUPDATE 1=0Atest=3D# select found;=0AERROR:= =A0 column "found" does not exist=0ALINE 1: select found;=0A=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 ^=0A=0Aplpgsql creates a FOUND variable and set= s it based on the rows=0Aaffected by various statements. Besides that, with= all the various=0APLs that are supported in PostgreSQL, littering the docu= mention of=0Aeach SQL statement with details of how that statement is suppo= rted=0Ain each PL would get really messy really quickly.=0A=0A-Kevin
В списке pgsql-bugs по дате отправления: