Excerpts from Robert Haas's message of mar jun 07 08:16:01 -0400 2011:
> On Tue, Jun 7, 2011 at 2:57 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> > Seems like you're trying to fix the problem directly, which as you
> > say, has problems.
> >
> > At some point we resolve from a word mentioned in the FROM clause to a
> > relfilenode.
> >
> > Surely somewhere there we can notice its unlogged before we end up
> > down in the guts of smgr?
>
> Probably. I guess the question is whether we want this to fail in (a)
> the parser, (b) the planner, or (c) the executor. I'm not quite sure
> what is best, but if I had to guess I would have picked (c) in
> preference to (b) in preference to (a), and you seem to be proposing
> (a). Having parserOpenTable() or transformSelectStmt() or some such
> place barf doesn't feel right - it's not the job of those functions to
> decide whether the query can actually be executed at the moment, just
> whether it's well-formed.
Really? I thought it was the job of the parse analysis phase to figure
out if table and column names are valid or not, and such. If that's the
case, wouldn't it make sense to disallow usage of a table that doesn't
"exist" in a certain sense?
--
Ãlvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support