Adam Mackler-3 wrote > If someone can answer this challenge > without imposing that requirement, then I shall be all the more > impressed. Fair enough; my goal wasn't to complete a challenge but to actually be practical. > The library I'm using is SLICK: > > http://slick.typesafe.com/ > > As far as I can tell it can't handle user-defined functions that > return multiple rows nor multiple columns, except perhaps through some > low-level SQL interface that would defeat my idea of the purpose of > using a database interface library. You seem to be trying to fix the wrong end of the problem then... > As I mention in the post on SO, my understanding of relational > database theory tells me that tables/relations ARE functions, in the > sense of being a mapping between a primary key and a row. So there's > nothing ambiguous about issuing a SELECT query for some particular > date, and if I'm only querying for one date, then there's only one day > in the resulting table. > > It wouldn't surprise me if there were some way to create a view based > on underlying tables that contain schedules for each day of the week > that I could query in such a fashion for any day arbitrarily far into > the future. If this is possible, then I would be interested in > knowing what the creation of such a view looks like, independently of > my immediate practical needs. Call me academic. Yes, there is probably some poorly performing and hard-to-maintain way to accomplish your goal using triggers, rules and materialized views. Relational theory only gets you so far. The actual tools implemented in PostgreSQL are what we have to work with and given the toolbox in hand, and my knowledge of it (which is reasonably complete but not perfect) a function API is, IMO, the most effective solution. If your method of coding cannot make use of that API you should decide what you want to do to handle such since this kind of API is quite common - at least in PostgreSQL which is all that I am concerned with for purposes of this discussion. I'm guessing that your ORM will allow you to handle this use-case in some manner otherwise it is not a very slick ORM. David J. -- View this message in context: http://postgresql.1045698.n5.nabble.com/Can-a-view-represent-a-schedule-for-all-days-into-the-future-tp5774069p5774115.html Sent from the PostgreSQL - general mailing list archive at Nabble.com. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
