Re: PLpgSQL: list of scalars as row for assign stmt, fore and fors stm - Mailing list pgsql-patches
From | Pavel Stehule |
---|---|
Subject | Re: PLpgSQL: list of scalars as row for assign stmt, fore and fors stm |
Date | |
Msg-id | BAY20-F6D6D4F2A8A4CA06C57EADF9310@phx.gbl Whole thread Raw |
In response to | Re: PLpgSQL: list of scalars as row for assign stmt, fore and fors stm (Tom Lane <tgl@sss.pgh.pa.us>) |
List | pgsql-patches |
> >"Pavel Stehule" <pavel.stehule@hotmail.com> writes: > >>>> x, y := r; > > > >>> That strikes me as a really bad idea. It weakens both syntax and > >>> semantic error checking, to accomplish how much? > >> > >> Could use PHP-style thingy: > >> LIST(x, y) := r; > >Actually, ROW(x, y) would be the right spelling per SQL convention. I am not sure. Allow SQL function on left side of assigment? > > > It's inconsystency :-(. > > EXECUTE INTO and SELECT INTO use scalar of vectors without anything. > >But in both of those cases there are required leading keywords to give >you some clue what's supposed to come next. Allowing bare x, y at the >start of a statement is just a recipe for misconstruing stuff that was >intended as something else and is one or two punctuation characters shy >of perfection. > Yes. But it's not neccessery or maybe T_SCALAR is keyword by self. And code of actual patch is very natural (but I have to use plpgsq_push_back_token()). If I use ROW(...) := syntax, I have to change for others statements: EXECUTE '...' INTO ROW(a,b,c); -- atc. FOR ROW(a,b,c) IN SELECT but it's not wrong idea? What do you think? I don't have objective arguments. It's questions personal preferences. What I know, some others languages has similar syntax. 1. a,b,c := r; -- C, Python 2. (a,b,c) := r; -- Perl 3. ROW(a,b,c) := r; -- Perl, PHP >There is also the problem of insufficient semantic cross-checking. A >record variable doesn't have any very well-defined order of fields, so >who's to say which value goes to x and which to y? For that matter, >if I just have > x := y >and y is a single-field rowtype, it'd be entirely unclear whether x is >to receive the row value or the field value. > Valid argument. And there is error in my patch now. Semantics is clean I think. You can use only declared variables and you know if var. is scalar or row/record. If x is scalar, then x will contain first field of y. But in this moment, I have to do implicit retyping - which can be wrong. And ROW(x) := y syntax is better. Oracle syntax don't allow list of variables here. It's argument. I'll change patch on ROW() := .. for test. >I don't think this buys anything that is worth the can of worms we'd >be opening up. The extension for FOR might be worth doing, but not >the assignment change. > It's depend. In my practic life, I spend time on code p1 := r.p1; p2 := r.p2; .... >And, to reiterate Andrew's point, this entire discussion should have >been held before you wrote a line of code. It is utterly wrong >to be doing it in pgsql-patches. I am sorry. I had to use different subject, like EXPERIMENTAL or PROPOSAL patch. Regards Pavel Stehule _________________________________________________________________ Citite se osamele? Poznejte nekoho vyjmecneho diky Match.com. http://www.msn.cz/
pgsql-patches by date: