On Thu, Feb 14, 2008 at 11:06:42AM -0500, Tom Lane wrote:
> =?UTF-8?B?UmFwaGHDq2wgSmFjcXVvdA==?= <[EMAIL PROTECTED]> writes:
> > so, I propose the use of
> > NEW[variable_containing_the_column_name]
> > (which can obviously be extended to any tuples)
> > to allow such access.
>
> > what do you experts think ?
>
> Zero chance. plplgsql is a strongly typed language, and a construct
> like that couldn't have any known-in-advance data type.
If "variable_containing_the_column_name" was a string then I agree,
if columns were first class objects then it wouldn't be a problem.
Introducing sub-types would make this all nice and tidy, but
unfortunately sub-types are a long way away from what PG currently
supports and I don't know the SQL spec well enough to know if there
would be any serious incompatibilities with them--they are pretty
expressive so I'd doubt there would be any fundamental incompatibility.
If you want an example, Java has sub-types and 1.5+ has parametric
polymorphism making it possible to create an interface that named the
column you were interested in and then to write a function like:
interface Column<Row,ColType> {
public ColType get(Row r);
}
public <Row,ColType> ColType foo(Row row, Column<Row,ColType> col) {
return col.get(row);
}
In PG you'd want the sub-types to be generated automatically, the above
example is somewhat unreadable. The only real purpose of the above was
to show how a strong type system can express what the OP wanted.
The anyelement and supporting polymorphism would all be subsumed into
the features provided by sub-typing and would all be done in a much
tidier way.
It's a very big change for PG though!
Sam
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
