Re: posgres 12 bug (partitioned table)
От | Tom Lane |
---|---|
Тема | Re: posgres 12 bug (partitioned table) |
Дата | |
Msg-id | 793243.1619032209@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: posgres 12 bug (partitioned table) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: posgres 12 bug (partitioned table)
Re: posgres 12 bug (partitioned table) |
Список | pgsql-bugs |
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
В списке pgsql-bugs по дате отправления: