"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.

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.

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

Reply via email to