Syntax for partitioning
in [PgSql]
|
Prev: [HACKERS] pg_read_file() and non-ascii input file
Next: [HACKERS] Proposal - temporal contrib module
From: Tom Lane on 30 Oct 2009 17:16 Jeff Davis <pgsql(a)j-davis.com> writes: > I haven't looked at all of these places yet, so maybe a few simple > changes would allow us to treat typmod as a full 32 bits. Or perhaps it > could just be expanded to a signed 64-bit int. What do you think? Neither is likely to happen, and even disregarding that, I doubt people would be real happy with a design like this. Where are you going to put the typmod for the contained type? regards, tom lane -- 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: Robert Haas on 30 Oct 2009 17:39 On Fri, Oct 30, 2009 at 5:16 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Jeff Davis <pgsql(a)j-davis.com> writes: >> I haven't looked at all of these places yet, so maybe a few simple >> changes would allow us to treat typmod as a full 32 bits. Or perhaps it >> could just be expanded to a signed 64-bit int. What do you think? > > Neither is likely to happen, and even disregarding that, I doubt people > would be real happy with a design like this. Where are you going to > put the typmod for the contained type? IMO, the real problem is that the type interface is poorly encapsulated. There's way too much code that knows about the internal details of a type - namely, that it's a 32-bit integer modified by a second 32-bit integer. I think there are still places where the code doesn't even know about typmod. If we're going to go to the trouble of changing anything, I think it should probably involve inserting an abstraction layer that will make future extensions easier. But I have a feeling that's going to be a tough sell. ....Robert -- 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: Jeff Davis on 30 Oct 2009 18:28 On Fri, 2009-10-30 at 17:39 -0400, Robert Haas wrote: > IMO, the real problem is that the type interface is poorly > encapsulated. There's way too much code that knows about the internal > details of a type - namely, that it's a 32-bit integer modified by a > second 32-bit integer. I think there are still places where the code > doesn't even know about typmod. If we're going to go to the trouble > of changing anything, I think it should probably involve inserting an > abstraction layer that will make future extensions easier. But I have > a feeling that's going to be a tough sell. Yeah. We're way off topic for partitioning, so I think it's best to just table this discussion until someone comes up with a good idea. It's not the end of the world to write some generic C code, and have multiple types make use of it, e.g. PERIOD, PERIODTZ, INT4RANGE, FLOAT8RANGE, etc. It's a little redundant and creates some catalog bloat, but I'm not too concerned about it right now. Certainly not enough to rewrite the type system. Regards, Jeff Davis -- 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: Tom Lane on 30 Oct 2009 18:44 Robert Haas <robertmhaas(a)gmail.com> writes: > IMO, the real problem is that the type interface is poorly > encapsulated. There's way too much code that knows about the internal > details of a type - namely, that it's a 32-bit integer modified by a > second 32-bit integer. I think there are still places where the code > doesn't even know about typmod. If we're going to go to the trouble > of changing anything, I think it should probably involve inserting an > abstraction layer that will make future extensions easier. But I have > a feeling that's going to be a tough sell. Yup, you're right. It would be an enormous amount of work and break a lot of third-party code, for largely hypothetical future benefits. We've got better places to invest our limited manpower. regards, tom lane -- 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: Itagaki Takahiro on 1 Nov 2009 19:12
Devrim GNDZ <devrim(a)gunduz.org> wrote: > 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 Regards, --- ITAGAKI Takahiro NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |