Kevin Grittner <kgri...@ymail.com> writes:
> Kevin Grittner <kgri...@ymail.com> wrote:
> The presence of default_with_oids and the special-handling of the
> oids option via interpretOidsOption() makes it hard to come up with
> a solution which would qualify as "elegant". Here's a rough cut at
> an approach which seems best to me. If this sits well with others
> I'll add comments and think about that error message some more.
This seems even grottier than the other way. I was expecting that it
should be taken care of during parse analysis; the grammar doesn't
have much more business than the executor dealing with this issue.
Let me think about it and see if I can propose a better fix.
> I'm not entirely sure I like accepting WITH (oids = false) but
> throwing an error on WITH (oids = true), but it seems marginally
> better than rejecting both.
Hm --- we'd need to deal with that issue regardless of just where in the
code it's going to happen. I think we definitely need to reject
WITH (oids = true), if that's not to be supported, but have less of
an opinion about the other.
BTW, is there a really solid reason why a matview couldn't be allowed to
have OIDs on demand, and thereby dodge this whole problem? I'm thinking
that the analogy to regular views not having OIDs is not a very good
argument, because certainly matview rows are going to need all the other
system columns.
[ wanders away wondering why IntoClause has grown a relkind field... ]
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
