Bryan Lee Nuse writes:
>> Now you're doubtless wondering why Postgres doesn't dodge this ambiguity
>> for you.
> This is exactly what I was wondering, of course. And I follow the reasoning
> behind why it cannot, at present. If Postgres can't ensure that the view
> definition is valid SQL, t
Thanks, Tom, for your helpful explanation and suggestions.
> Now you're doubtless wondering why Postgres doesn't dodge this ambiguity
> for you.
This is exactly what I was wondering, of course. And I follow the reasoning
behind why it cannot, at present. If Postgres can't ensure that the view
Bryan Lee Nuse writes:
> My question is, then, how is it that the query embodied in "view_1" below
> executes fine, but cannot seem to be restored? Is this telling me my query
> is dumb? If so, any advice on how to easily derive "view_1" from "tab_1" and
> "tab_2" below, without baffling pg_r
Greetings, list,
I have a VIEW I use to combine both acquired and missing field observations.
Because of they way these data will be used, missing values can't be NULL. So
I make them some outrageous integer value, like -999. I put the full VIEW
together using UNION.
As shown in the test ca
