pg.ddx.io  pgsql-bugs@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Amit Langote <amitlangote09@gmail.com>
Cc: David Steele <david@pgmasters.net>
Cc: Pavel Biryukov <79166341370@yandex.ru>
Cc: Andres Freund <andres@anarazel.de>
Cc: PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Subject: Re: posgres 12 bug (partitioned table)
Date: Wed, 21 Apr 2021 15:10:09 -0400
Message-ID: <793243.1619032209@sss.pgh.pa.us> (raw)
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>

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





view thread (46+ messages)  latest in thread

Message-ID: <793243.1619032209@sss.pgh.pa.us>
Permalink:  ../793243.1619032209@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/793243.1619032209@sss.pgh.pa.us

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-bugs@postgresql.org
  Cc: tgl@sss.pgh.pa.us, amitlangote09@gmail.com, david@pgmasters.net, 79166341370@yandex.ru, andres@anarazel.de, pgsql-bugs@lists.postgresql.org
  Subject: Re: posgres 12 bug (partitioned table)
  In-Reply-To: <793243.1619032209@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox