Re: [PATCHES] PLpgSQL: list of scalars as row for assign stmt, fore
On Wed, Dec 21, 2005 at 09:26:35AM +0800, Christopher Kings-Lynne wrote: > >> 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; Better still, the pg way: [ROW](x, y) := r; Cheers, D -- David Fetter [EMAIL PROTECTED] http://fetter.org/ phone: +1 415 235 3778 Remember to vote! ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] PLpgSQL: list of scalars as row for assign stmt, fore and fors stm
"Pavel Stehule" <[EMAIL PROTECTED]> 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/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] PLpgSQL: list of scalars as row for assign stmt, fore and fors stm
"Pavel Stehule" <[EMAIL PROTECTED]> 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. > 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. 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. 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. 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. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] PLpgSQL: list of scalars as row for assign stmt, fore
Pavel Stehule wrote: 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; Chris It's inconsystency :-(. EXECUTE INTO and SELECT INTO use scalar of vectors without anything. ROW(x, y) := r; :) Chris ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] PLpgSQL: list of scalars as row for assign stmt, fore and fors stm
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; Chris It's inconsystency :-(. EXECUTE INTO and SELECT INTO use scalar of vectors without anything. Pavel _ Najdete si svou lasku a nove pratele na Match.com. http://www.msn.cz/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] PLpgSQL: list of scalars as row for assign stmt, fore
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; Chris ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] PLpgSQL: list of scalars as row for assign stmt, fore and fors stm
Tom Lane said: > "Pavel Stehule" <[EMAIL PROTECTED]> writes: >> x, y := r; > > That strikes me as a really bad idea. It weakens both syntax and > semantic error checking, to accomplish how much? > Where does the idea come from anyway? Has it been discussed on -hackers? I don't recall seeing it. Just sending in a patch for a "feature" you think is a good idea seems like a sub-optimal process. No, this only my idea. I miss this functionality in fors and fore stmts. You are true, so is better start discussion on this topic on hackers. But I can't send attachments to -hackers. And I am not hacker or developer. I did patch only. All others is on core hackers. Regards Pavel Stehule _ Emotikony a pozadi programu MSN Messenger ozivi vasi konverzaci. http://messenger.msn.cz/ ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] PLpgSQL: list of scalars as row for assign stmt, fore and fors stm
"Pavel Stehule" <[EMAIL PROTECTED]> writes: > x, y := r; That strikes me as a really bad idea. It weakens both syntax and semantic error checking, to accomplish how much? It's same as select into or execute into (using same code). And behave is like row variable := row variable. I am not sure if it's good idea. But it's can be usefull when you have out variables and you have to fill them. There are not control for count of arguments, but types are checked. I can understand so this topic is little bit controvers. And maybe we don't need this statements, if we have this possibility in fore and fors stmts. Regards Pavel Stehule _ Emotikony a pozadi programu MSN Messenger ozivi vasi konverzaci. http://messenger.msn.cz/ ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] PLpgSQL: list of scalars as row for assign stmt, fore and fors stms
Tom Lane said: > "Pavel Stehule" <[EMAIL PROTECTED]> writes: >> x, y := r; > > That strikes me as a really bad idea. It weakens both syntax and > semantic error checking, to accomplish how much? > Where does the idea come from anyway? Has it been discussed on -hackers? I don't recall seeing it. Just sending in a patch for a "feature" you think is a good idea seems like a sub-optimal process. cheers andrew ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] PLpgSQL: list of scalars as row for assign stmt, fore and fors stms
"Pavel Stehule" <[EMAIL PROTECTED]> writes: > x, y := r; That strikes me as a really bad idea. It weakens both syntax and semantic error checking, to accomplish how much? regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
