Kevin Grittner writes:
> In working up a patch for this approach, I see that if CREATE
> FOREIGN TABLE is executed with default_with_oids set to true, it
> adds an oid column which appears to be always zero in my tests so
> far (although maybe other FDWs support it?). Do we want to leave
> that a
Kevin Grittner wrote:
> Kevin Grittner wrote:
>> Robert Haas wrote:
>
>>> It seems to me that the right place to fix this is in
>>> interpretOidsOption(), by returning false rather than
>>> default_with_oids whenever the relation is a materialized view.
>
>> I like it.
>
> In working up a patch
Kevin Grittner wrote:
> Robert Haas wrote:
>> It seems to me that the right place to fix this is in
>> interpretOidsOption(), by returning false rather than
>> default_with_oids whenever the relation is a materialized view.
> I like it.
In working up a patch for this approach, I see that if CR
Robert Haas wrote:
> Kevin Grittner wrote:
>> I want to give everyone else a chance to weigh in before I start
>> the pendulum swinging back in the other direction on OIDs in MVs.
>> Opinions?
>
> I agree that it's probably better to just disallow this, but I have to
> admit I don't like your pro
On Mon, Mar 18, 2013 at 4:42 PM, Kevin Grittner wrote:
> I want to give everyone else a chance to weigh in before I start
> the pendulum swinging back in the other direction on OIDs in MVs.
> Opinions?
I agree that it's probably better to just disallow this, but I have to
admit I don't like your
Tom Lane wrote:
> Kevin Grittner writes:
>> Tom Lane wrote:
>>> [ why not allow matviews to have OID columns? ]
>
>> An oid column in a materialized view will not be significantly more
>> stable than its ctid. The same "logical" row could easily have a
>> different OID on a REFRESH or even an i
Kevin Grittner writes:
> Tom Lane wrote:
>> [ why not allow matviews to have OID columns? ]
> An oid column in a materialized view will not be significantly more
> stable than its ctid. The same "logical" row could easily have a
> different OID on a REFRESH or even an incremental update (due to
Tom Lane wrote:
> I wrote:
>> 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
I wrote:
> 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
Tom Lane wrote:
> [ wanders away wondering why IntoClause has grown a relkind field... ]
See transformCreateTableAsStmt, SetupForCreateTableAs, intorel_startup.
gram.y uses the convention of assigning '\0' to it initially and parse
analysis fills in the right value. I wonder if a boolean field w
Kevin Grittner writes:
> Kevin Grittner 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
Kevin Grittner wrote:
> Tom Lane wrote:
>> Kevin Grittner writes:
>>> I failed to touch everything necessary to prevent MVs from
>>> having OIDs. This patch fixes the reported problem, and
>>> doesn't leave any gaps as far as I know; but I will do
>>> additional review to try to catch any other
Tom Lane wrote:
> Kevin Grittner writes:
>> I failed to touch everything necessary to prevent MVs from
>> having OIDs. This patch fixes the reported problem, and doesn't
>> leave any gaps as far as I know; but I will do additional review
>> to try to catch any other omissions. I figured I shoul
Kevin Grittner writes:
> I failed to touch everything necessary to prevent MVs from having
> OIDs. This patch fixes the reported problem, and doesn't leave any
> gaps as far as I know; but I will do additional review to try to
> catch any other omissions. I figured I should address the reported
Joachim Wieland wrote:
> I'm getting an assertion failure in HEAD with materialized views
> To reproduce, just run make installcheck, dump the regression
> database and then restore it, the server crashes during restore.
I failed to touch everything necessary to prevent MVs from having
OIDs. T
On Tue, Mar 5, 2013 at 9:11 AM, Kevin Grittner wrote:
> Will investigate.
> You don't have default_with_oids = on, do you?
No, this was a default install with a default postgresql.conf
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
h
Joachim Wieland wrote:
> I'm getting an assertion failure in HEAD with materialized views, see
> below for backtrace.
>
> To reproduce, just run make installcheck, dump the regression database
> and then restore it, the server crashes during restore.
> #2 0x00888429 in ExceptionalCondit
I'm getting an assertion failure in HEAD with materialized views, see
below for backtrace.
To reproduce, just run make installcheck, dump the regression database
and then restore it, the server crashes during restore.
(gdb) bt
#0 0x7f283a366425 in raise () from /lib/x86_64-linux-gnu/libc.so.
18 matches
Mail list logo
