From: Tom Lane <tgl@sss.pgh.pa.us>
To: Amit Langote <amitlangote09@gmail.com>
cc: David Steele <david@pgmasters.net>,
 Pavel Biryukov <79166341370@yandex.ru>,
        Andres Freund <andres@anarazel.de>,
        PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Subject: Re: posgres 12 bug (partitioned table)
In-reply-to: 
 <CA+HiwqHqnC=A9a+=F-k8J=JV-EKKt3vTgxq01=9af-0HE045NQ@mail.gmail.com>
References: <141051591267657@mail.yandex.ru>
 <1251598.1591289850@sss.pgh.pa.us>
 <20200811180231.fcssvhelqpnydnx7@alap3.anarazel.de>
 <CA+HiwqH7bA+orwhcA5dofKR_UNzk-S8GPK23g1vCrWxAjnK=Og@mail.gmail.com>
 <81885.1597205290@sss.pgh.pa.us>
 <CA+HiwqFx8oBGTDmwVQNHQrSGw4we84E4z5J+q2zFRJeAt5BaCA@mail.gmail.com>
 <20200812162718.ycxrktzoe6rpdy5k@alap3.anarazel.de>
 <CA+HiwqEGgy8x5M2dotzH7HSd0v+byyJXGU8S+d5NFnrOBiTZDA@mail.gmail.com>
 <407111603806900@mail.yandex.ru>
 <CA+HiwqFjEim_RMCiaFxA4nUx00o3auXKPy-OsOcog+chg5K-zA@mail.gmail.com>
 <cd492dbd-a0ba-4790-bcf7-c4af2d2dc8d1@pgmasters.net>
 <CA+HiwqG7qhKJnFpZOqyrFngqcMzja+p=gssMK=73b+-BZffxqw@mail.gmail.com>
 <CA+HiwqHqnC=A9a+=F-k8J=JV-EKKt3vTgxq01=9af-0HE045NQ@mail.gmail.com>
Comments: In-reply-to Amit Langote <amitlangote09@gmail.com>
	message dated "Fri, 12 Mar 2021 21:47:18 +0900"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <793242.1619032209.1@sss.pgh.pa.us>
Date: Wed, 21 Apr 2021 15:10:09 -0400
Message-ID: <793243.1619032209@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/793243.1619032209%40sss.pgh.pa.us>
Precedence: bulk

Amit Langote <amitlangote09@gmail.com> writes:
> Forgot to ask in the last reply: for HEAD, should we consider simply
> preventing accessing system columns when querying through a parent
> partitioned table, as was also mentioned upthread?

Indeed, it seems like this thread is putting a fair amount of work
into a goal that we shouldn't even be trying to do.  We gave up the
assumption that a partitioned table's children would have consistent
system columns the moment we decided to allow foreign tables as
partition leaf tables; and it's only going to get worse as alternate
table AMs become more of a thing.  So now I'm thinking the right thing
to be working on is banning access to system columns via partition
parent tables (other than tableoid, which ought to work).

I'm not quite sure whether the right way to do that is just not
make pg_attribute entries for system columns of partitioned tables,
as we do for views; or make them but have a code-driven error if
you try to use one in a query.  The second way is uglier, but
it should allow a more on-point error message.  OTOH, if we start
to have different sets of system columns for different table AMs,
we can't have partitioned tables covering all of those sets.

In the meantime, if the back branches fail with something like
"virtual tuple table slot does not have system attributes" when
trying to do this, that's not great but I'm not sure we should
be putting effort into improving it.

			regards, tom lane