> I think there are some difficulties too when it comes to type casting. > A "selectFrom(Cities.CITIES)" will return some CitiesRecords that are > in fact CapitalsRecords.
But when you select from CITIES, then you will actually only get the cities records. Even if some records are in fact capitals, their known type is only Cities, I think? What I mean is this: --------------------------------------------------------------- -- this will only return cities that are capitals. The state column is included SELECT * FROM capitals -- this will return all cities, but not the state column SELECT * FROM cities --------------------------------------------------------------- If that's really the behaviour, then I don't think that casting is going to be needed. On the other hand, I know that Oracle also knows of abstract / non-instantiable types. If Postgres does, too, then things may become more complicated. > There needs to be some way to cast them to > CapitalsRecord. You could probably add the pg_class.relname column > (see PostgreSQL page) to every selectFrom-generated SQL to find out > what the actual subtype of returned 'cities' records is and add a > CapitalsRecord to the Result set instead of a CitiesRecord when > appropriate, but then you're still missing the CapitalsRecord's > 'state' value. pg_class.relname is probably the correct way to do this. But again, why do you think we'd need the cast to CapitalsRecord? After all, what is selected here is a CitiesRecord. And city.store() would correctly store the "city-part" of a capital, if it is a capital...
