Merlin Moncure <mmonc...@gmail.com> writes:
> On Mon, Mar 15, 2010 at 10:02 AM, Andrew Dunstan <and...@dunslane.net> wrote:
>> Not quite, but close. We also need a nice way of querying for field names
>> (at least) at run time. I've seen that requested several times.
> does the parse/plan objection still hold?
Yeah. Providing the field names isn't the dubious part --- the dubious
part is what are you going to *do* with them. It's difficult to see
applications in which you can make the simplifying assumption that the
actual field datatypes are known/fixed. Using field numbers instead of
names doesn't get you out from under that. (Though I like the idea
insofar as it simplifies the looping mechanism.)
If we make the implementation be such that "(rec->field)::foo" forces
a runtime cast to foo (rather than throwing an error if it's not type
foo already), then it's possible to suppose that this sort of application
could be catered to by forcing all the fields to text, or some other
generic datatype. This at least puts the text dependency out where the
user can see it, though it still seems rather inelegant. It also takes
away possible error detection in other circumstances where a forced cast
isn't really wanted.
The cost of looking up the ever-changing cast function could still be
unpleasant, although I think we could hide it in the executor expression
node instead of forcing a whole new parse/plan cycle each time.
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
