Обсуждение: [JDBC] Postgres 10 partitioned tables
The current JDBC driver returns no information about the new partitioned tables in the upcoming Postgres 10. This is caused by the fact that partitioned tables have a new pg_class.relkind value: 'p' I have attached a simple patch that fixes the obvious problem that partitioned tables are not returned by getTables() andno column information is returned from getColumns(). The patch essentially treats relkind 'r' and 'p' the same because I think the driver should not make a distinction betweenregular tables and partitioned tables. But I think the bigger is: what do do with the partitions themselves? Technically they are tables, but I think it would make sense to hide them and let frontend tools deal with displaying partitionsbelonging to a table (this is e.g. how Oracle does it). However, psql displays them as regular tables just like with the "old" inheritance partitions, so that would probably causesome confusion if getTables() did not return those tables. Thomas
Вложения
Thomas,
thanks for this !
As for the answer to your question. I have no idea what to do with them.
On 13 May 2017 at 07:09, Thomas Kellerer <spam_eater@gmx.net> wrote:
The current JDBC driver returns no information about the new partitioned tables in the upcoming Postgres 10.
This is caused by the fact that partitioned tables have a new pg_class.relkind value: 'p'
I have attached a simple patch that fixes the obvious problem that partitioned tables are not returned by getTables() and no column information is returned from getColumns().
The patch essentially treats relkind 'r' and 'p' the same because I think the driver should not make a distinction between regular tables and partitioned tables.
But I think the bigger is: what do do with the partitions themselves?
Technically they are tables, but I think it would make sense to hide them and let frontend tools deal with displaying partitions belonging to a table (this is e.g. how Oracle does it).
However, psql displays them as regular tables just like with the "old" inheritance partitions, so that would probably cause some confusion if getTables() did not return those tables.
Thomas
--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc
Thomas,
thanks for this !
As for the answer to your question. I have no idea what to do with them.
On 13 May 2017 at 07:09, Thomas Kellerer <spam_eater@gmx.net> wrote:
The current JDBC driver returns no information about the new partitioned tables in the upcoming Postgres 10.
This is caused by the fact that partitioned tables have a new pg_class.relkind value: 'p'
I have attached a simple patch that fixes the obvious problem that partitioned tables are not returned by getTables() and no column information is returned from getColumns().
The patch essentially treats relkind 'r' and 'p' the same because I think the driver should not make a distinction between regular tables and partitioned tables.
But I think the bigger is: what do do with the partitions themselves?
Technically they are tables, but I think it would make sense to hide them and let frontend tools deal with displaying partitions belonging to a table (this is e.g. how Oracle does it).
However, psql displays them as regular tables just like with the "old" inheritance partitions, so that would probably cause some confusion if getTables() did not return those tables.
Thomas
--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc
IMHO, it's best to let the generic getTables() simply return all of the tables. Front end tools that need to do special things with different types of tables need to use PG specific meta data anyway.
--Luss
On Sun, May 14, 2017 at 7:39 AM, Dave Cramer <pg@fastcrypt.com> wrote:
Thomas,thanks for this !As for the answer to your question. I have no idea what to do with them.On 13 May 2017 at 07:09, Thomas Kellerer <spam_eater@gmx.net> wrote:--The current JDBC driver returns no information about the new partitioned tables in the upcoming Postgres 10.
This is caused by the fact that partitioned tables have a new pg_class.relkind value: 'p'
I have attached a simple patch that fixes the obvious problem that partitioned tables are not returned by getTables() and no column information is returned from getColumns().
The patch essentially treats relkind 'r' and 'p' the same because I think the driver should not make a distinction between regular tables and partitioned tables.
But I think the bigger is: what do do with the partitions themselves?
Technically they are tables, but I think it would make sense to hide them and let frontend tools deal with displaying partitions belonging to a table (this is e.g. how Oracle does it).
However, psql displays them as regular tables just like with the "old" inheritance partitions, so that would probably cause some confusion if getTables() did not return those tables.
Thomas
Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc
IMHO, it's best to let the generic getTables() simply return all of the tables. Front end tools that need to do special things with different types of tables need to use PG specific meta data anyway.
--Luss
On Sun, May 14, 2017 at 7:39 AM, Dave Cramer <pg@fastcrypt.com> wrote:
Thomas,thanks for this !As for the answer to your question. I have no idea what to do with them.On 13 May 2017 at 07:09, Thomas Kellerer <spam_eater@gmx.net> wrote:--The current JDBC driver returns no information about the new partitioned tables in the upcoming Postgres 10.
This is caused by the fact that partitioned tables have a new pg_class.relkind value: 'p'
I have attached a simple patch that fixes the obvious problem that partitioned tables are not returned by getTables() and no column information is returned from getColumns().
The patch essentially treats relkind 'r' and 'p' the same because I think the driver should not make a distinction between regular tables and partitioned tables.
But I think the bigger is: what do do with the partitions themselves?
Technically they are tables, but I think it would make sense to hide them and let frontend tools deal with displaying partitions belonging to a table (this is e.g. how Oracle does it).
However, psql displays them as regular tables just like with the "old" inheritance partitions, so that would probably cause some confusion if getTables() did not return those tables.
Thomas
Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc
I have updated the patch to also include proper handling of the new identity columns. getColumns() now returns YES for IS_AUTOINCREMENT I tried to find out how to do this via Github, but the Github manual only says I need to push my commit to a branch, buteven if I create a local tracking branch I can't push that, so I am a bit lost (never worked with Github before and gititself doesn't like me anyway)
Вложения
I have updated the patch to also include proper handling of the new identity columns. getColumns() now returns YES for IS_AUTOINCREMENT I tried to find out how to do this via Github, but the Github manual only says I need to push my commit to a branch, buteven if I create a local tracking branch I can't push that, so I am a bit lost (never worked with Github before and gititself doesn't like me anyway)
Thomas,
Thanks!
So for github you need to clone the repo into your own. Then add your repo as a remote to the pgjdbc repo. Then you can push to your repo on a different branch and create pull requests.
On 17 May 2017 at 15:42, Thomas Kellerer <spam_eater@gmx.net> wrote:
I have updated the patch to also include proper handling of the new identity columns. getColumns() now returns YES for IS_AUTOINCREMENT
I tried to find out how to do this via Github, but the Github manual only says I need to push my commit to a branch, but even if I create a local tracking branch I can't push that, so I am a bit lost (never worked with Github before and git itself doesn't like me anyway)
--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc
Thomas,
Thanks!
So for github you need to clone the repo into your own. Then add your repo as a remote to the pgjdbc repo. Then you can push to your repo on a different branch and create pull requests.
On 17 May 2017 at 15:42, Thomas Kellerer <spam_eater@gmx.net> wrote:
I have updated the patch to also include proper handling of the new identity columns. getColumns() now returns YES for IS_AUTOINCREMENT
I tried to find out how to do this via Github, but the Github manual only says I need to push my commit to a branch, but even if I create a local tracking branch I can't push that, so I am a bit lost (never worked with Github before and git itself doesn't like me anyway)
--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc
On 18 May 2017 at 06:36, Dave Cramer <pg@fastcrypt.com> wrote:
Thomas,Thanks!So for github you need to clone the repo into your own. Then add your repo as a remote to the pgjdbc repo. Then you can push to your repo on a different branch and create pull requests.On 17 May 2017 at 15:42, Thomas Kellerer <spam_eater@gmx.net> wrote:I have updated the patch to also include proper handling of the new identity columns. getColumns() now returns YES for IS_AUTOINCREMENT
I tried to find out how to do this via Github, but the Github manual only says I need to push my commit to a branch, but even if I create a local tracking branch I can't push that, so I am a bit lost (never worked with Github before and git itself doesn't like me anyway)
--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc
On 18 May 2017 at 06:36, Dave Cramer <pg@fastcrypt.com> wrote:
Thomas,Thanks!So for github you need to clone the repo into your own. Then add your repo as a remote to the pgjdbc repo. Then you can push to your repo on a different branch and create pull requests.On 17 May 2017 at 15:42, Thomas Kellerer <spam_eater@gmx.net> wrote:I have updated the patch to also include proper handling of the new identity columns. getColumns() now returns YES for IS_AUTOINCREMENT
I tried to find out how to do this via Github, but the Github manual only says I need to push my commit to a branch, but even if I create a local tracking branch I can't push that, so I am a bit lost (never worked with Github before and git itself doesn't like me anyway)
--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc
Thomas>I have updated the patch
Thanks for the patch, however it looks a bit odd when order of 'r','p' differs from line to line.
Can you please use some consistent order for r and p?
Vladimir
Vladimir
Thomas>I have updated the patch
Thanks for the patch, however it looks a bit odd when order of 'r','p' differs from line to line.
Can you please use some consistent order for r and p?
Vladimir
Vladimir
I've reordered them in my PR
On 18 May 2017 at 10:56, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote:
Thomas>I have updated the patchThanks for the patch, however it looks a bit odd when order of 'r','p' differs from line to line.Can you please use some consistent order for r and p?
Vladimir
I've reordered them in my PR
On 18 May 2017 at 10:56, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote:
Thomas>I have updated the patchThanks for the patch, however it looks a bit odd when order of 'r','p' differs from line to line.Can you please use some consistent order for r and p?
Vladimir
Thomas Kellerer schrieb am 13.05.2017 um 13:09: > But I think the bigger is: what do do with the partitions > themselves? > > Technically they are tables, but I think it would make sense to hide > them and let frontend tools deal with displaying partitions belonging > to a table (this is e.g. how Oracle does it). > > However, psql displays them as regular tables just like with the > "old" inheritance partitions, so that would probably cause some > confusion if getTables() did not return those tables. Turns out that this is being discussed for psql as well: https://www.postgresql.org/message-id/flat/6d0e4eb7-c2a9-c4cd-f9bc-1a1722f878d2%40catalyst.net.nz#6d0e4eb7-c2a9-c4cd-f9bc-1a1722f878d2@catalyst.net.nz Including a suggestion (patch) display partitions with a different type in the \d output. If that patch gets accepted/committed, maybe the driver should be adjusted to also return "PARTITION" as the table type insteadof TABLE. That might however, break applications that know how to deal with TABLEs but have no notion that a PARTITION can be treatedas that as well. Thomas
Thomas Kellerer schrieb am 13.05.2017 um 13:09: > But I think the bigger is: what do do with the partitions > themselves? > > Technically they are tables, but I think it would make sense to hide > them and let frontend tools deal with displaying partitions belonging > to a table (this is e.g. how Oracle does it). > > However, psql displays them as regular tables just like with the > "old" inheritance partitions, so that would probably cause some > confusion if getTables() did not return those tables. Turns out that this is being discussed for psql as well: https://www.postgresql.org/message-id/flat/6d0e4eb7-c2a9-c4cd-f9bc-1a1722f878d2%40catalyst.net.nz#6d0e4eb7-c2a9-c4cd-f9bc-1a1722f878d2@catalyst.net.nz Including a suggestion (patch) display partitions with a different type in the \d output. If that patch gets accepted/committed, maybe the driver should be adjusted to also return "PARTITION" as the table type insteadof TABLE. That might however, break applications that know how to deal with TABLEs but have no notion that a PARTITION can be treatedas that as well. Thomas