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