Neil Conway <[EMAIL PROTECTED]> writes:
> Titus von Boxberg wrote:
>> What do you mean by "right syntax". There are hundreds of examples
>> in programming languages where a "small" syntactic difference leads to
>> totally different semantics.
> Well, I'm just not happy that "foo.bar" means something completely
> different than "foo%bar" -- foo%bar isn't even fetching something called
> "bar" from "foo".
There's a worse objection, which is that % is a perfectly valid operator
name (typically defined as modulo). The patch is therefore usurping
syntax of an existing feature, which is surely Right Out.
Another small problem with the patch is the untenable assumption that
neither FIELDNAMES nor NFIELDS is ever used by anyone as an actual field
name.
Assuming that we're inventing in a green field, I'd suggest a syntax
along this line:
recordvalue.(stringexpression)
which is not confusable with any currently-valid syntax. I'm not sure
what to do about FIELDNAMES --- perhaps this would work:
recordvalue.(*)
As for NFIELDS, I don't think we need it -- you can always measure the
length of the FIELDNAMES array.
But the real $64 question for plpgsql stuff is "what does Oracle do?"
Is there any remotely comparable functionality in PL/SQL, and if so
what does it look like?
regards, tom lane
---------------------------(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
