I wrote: > ... Maybe it would > work to devise a notation that allows fetching or storing a field that > has a runtime-determined name, but prespecifies the field type. > Actually only the "fetch" end of it is an issue, since when storing the > field datatype can be inferred from the expression you're trying to > assign to the field.
[ after more thought ] I wonder if it could work to treat the result of a "record->fieldname" operator as being of UNKNOWN type initially, and resolve its actual type in the parser in the same way we do for undecorated literals and parameters, to wit * you can explicitly cast it, viz (record->fieldname)::bigint * you can let it be inferred from context, such as the type of whatever it's compared to * throw error if type is not inferrable Then at runtime, if the actual type of the field turns out to not be what the parser inferred, either throw error or attempt a run-time type coercion. Throwing error seems safer, because it would avoid surprises of both semantic (unexpected behavior) and performance (expensive conversion you weren't expecting to happen) varieties. But possibly an automatic coercion would be useful enough to justify those risks. BTW the same coerce-or-throw-error choice would arise on the "store" side, if the expression to be stored turns out to not exactly match the field type. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers