Hi Tom,
> In any case, it appears to me that your gripe has little to do with
> whether there's actually any enforcement of the not-null condition,
> and much to do with whether some unspecified client-side software
> thinks the query result column is guaranteed not null. Most likely
> you're going to have to fix the client-side software, because it's
> extrapolating things that Postgres does not tell it.
That's not entirely true. The client software obtains the type
information by querying Postgresql, namely by checking the attnotnull
column in the pg_attribute catalog. Therefore, this is not an
inference error on the client side, but instead a case of Postgresql
providing wrong information.
Well, we could argue all day on whether this is a bug or a feature,
but the fact is that it is a huge setback for me. I wanted my clients
to access the database indirectly, via a function such as get_movies,
but this problem makes that impossible.
I also thought that instead of using a function, I could create a view,
and the clients could use it to access the database. But there's also
a problem with this solution: as far as I'm aware, views in Postgresql
cannot accept parameters. While the simple example does not need
parametrized views, the real world app would need them.
So, barring functions and views, is there any other way to encapsulate
the inner workings of a query away from clients?
Thanks again for your help,
C.S.
____________________________________________________________________________________
Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out.
http://answers.yahoo.com/dir/?link=list&sid=396545469
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
