Syntax for partitioning
in [PgSql]
|
Prev: [HACKERS] pg_read_file() and non-ascii input file
Next: [HACKERS] Proposal - temporal contrib module
From: Nikhil Sontakke on 2 Nov 2009 01:02 Hi, >> Is this the same as / similar to Oracle's syntax? > > Yes. > >> IIRC Nikhil's patch was Oracle's syntax > > No. See: > http://download.oracle.com/docs/cd/B28359_01/server.111/b28286/statements_7002.htm#i2125922 > Any decent prevalent partitioning syntax should be ok IMHO. IIRC, MySQL paritioning syntax is also pretty similar to Oracle's. Regards, Nikhils -- http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Marko Tiikkaja on 17 Nov 2009 14:33 Hi, I'm reviewing your patch. The patch applies without problems and the feature works as advertised. I have yet to look at the code in detail, but it looks sane and seems to work. However, this looks like a mistake: partinfo = (PartitionInfo *) malloc(ntups * sizeof(PartitionInfo)); or am I missing something? The syntax itself seems a bit weird in some cases. Say you have: PARTITION BY RANGE ( foo USING > ) ( PARTITION bar VALUES LESS THAN 0 ); which translates to CHECK (bar > 0). That doesn't sound at all like LESS THAN to me. This syntax seems to be the same Oracle uses, and I think it's nice for the general case, but I think the reversed operator weirdness is a bit too much. Maybe we should use something like PARTITION bar VALUES OPERATOR 0 when the user specifies the operator? Regards, Marko Tiikkaja -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Jaime Casanova on 17 Nov 2009 14:46 On Thu, Nov 12, 2009 at 5:54 AM, Itagaki Takahiro <itagaki.takahiro(a)oss.ntt.co.jp> wrote: > I added psql and pg_dump support to Partitioning Syntax patch. > Paritioning information can be retrieved with a new system function > pg_get_partitiondef(parentRelid). Both psql and pg_dump use it. > i haven't seen the patch but: > >  * If a table with the same name already exists when a partition >   is created, the table is re-used as partition. This behavior >   is required for pg_dump to be simple. > i guess the table must be empty, if not we should be throw an error... and i actually prefer some more explicit syntax for this not just reusing a table >    PARTITION name VALUES LESS THAN { range_upper | MAXVALUE } >   | PARTITION name VALUES IN ( list_value [,...] | DEFAULT ) > i remember someone making a comment about actually using operators instead of LESS THEN and family -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL AsesorÃa y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Marko Tiikkaja on 17 Nov 2009 15:09 Jaime Casanova wrote: >> * If a table with the same name already exists when a partition >> is created, the table is re-used as partition. This behavior >> is required for pg_dump to be simple. >> > > i guess the table must be empty, if not we should be throw an error... > and i actually prefer some more explicit syntax for this not just > reusing a table I'd be OK with only a notification - even if the table wasn't empty -, similar to how inheritance combines rows currently. The patch currently silently reuses the table unless it has rows which don't satisfy the CHECK constraint, in which case it gives you the default CHECK constraint error. >> PARTITION name VALUES LESS THAN { range_upper | MAXVALUE } >> | PARTITION name VALUES IN ( list_value [,...] | DEFAULT ) >> > > i remember someone making a comment about actually using operators > instead of LESS THEN and family That doesn't sound like a bad idea.. Regards, Marko Tiikkaja -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Simon Riggs on 17 Nov 2009 16:31
On Thu, 2009-10-29 at 11:15 +0900, Itagaki Takahiro wrote: > I think syntax support is a good start. I don't see a syntax-only patch as being any use at all to this community. We go to enormous lengths in other areas to never allow patches with restrictions. Why would we allow a patch that is essentially 100% restriction? i.e. It does nothing at all. Worse than that, it will encourage people to believe it exists in full, when that isn't the case. The syntax has never really been in question, so it doesn't really move us forwards in any direction. This is exactly the kind of shallow feature we have always shied away from and that other databases have encouraged. The only reason I can see is that it allows people to develop non-open source code that matches how Postgres will work when we get our act together. That seems likely to discourage, rather than encourage the funding of this work for open source. It may even muddy the water for people that don't understand that the real magic happens in the internals, not in the syntax. Why not just wait until we have a whole patch and then apply? -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |