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
