Re: [HACKERS] [pgsql-www] Mentors needed urgently for SoC PostgreSQL Student Internships
Note that since the Internships are not required to be project code, we can also take student projects to contribute to our WWW infrastructure and other areas the project needs some work. Would introducing a Duration (i.e., time-series a'la Date, et al)) data type be considered useful? I'd be happy to mentor someone doing it instead of having to write the entire thing myself. -- Steven Lembark85-09 90th St. Workhorse Computing Woodhaven, NY, 11421 lemb...@wrkhors.com +1 888 359 3508 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] Mentors needed urgently for SoC PostgreSQL Student Internships
On Apr 2, 2009, at 7:20 AM, Steven Lembark wrote: Note that since the Internships are not required to be project code, we can also take student projects to contribute to our WWW infrastructure and other areas the project needs some work. Would introducing a Duration (i.e., time-series a'la Date, et al)) data type be considered useful? I'd be happy to mentor someone doing it instead of having to write the entire thing myself. +1 David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] Mentors needed urgently for SoC PostgreSQL Student Internships
On 4/2/09 8:48 AM, David E. Wheeler wrote: On Apr 2, 2009, at 7:20 AM, Steven Lembark wrote: Note that since the Internships are not required to be project code, we can also take student projects to contribute to our WWW infrastructure and other areas the project needs some work. Would introducing a Duration (i.e., time-series a'la Date, et al)) data type be considered useful? Jeff Davis has already done a lot of this work; it's on pgFOundry somewhere. --Josh -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] Mentors needed urgently for SoC PostgreSQL Student Internships
Josh Berkus wrote: On 4/2/09 8:48 AM, David E. Wheeler wrote: On Apr 2, 2009, at 7:20 AM, Steven Lembark wrote: Note that since the Internships are not required to be project code, we can also take student projects to contribute to our WWW infrastructure and other areas the project needs some work. Would introducing a Duration (i.e., time-series a'la Date, et al)) data type be considered useful? Jeff Davis has already done a lot of this work; it's on pgFOundry somewhere. The data type itself is quite trivial. It's all the operators that are more difficult to implement, and also immensely useful. That part is still incomplete. I'd recommend a book called Temporal Data and the Relational Model by C.J. Date, Hugh Darwen and Nikos Lorentzos for anyone interested in this topic. That book gives a guideline on how the data type and operators should behave. I'd love to see that implemented. I volunteer to mentor if someone wants to tackle it. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] Mentors needed urgently for SoC PostgreSQL Student Internships
On Thu, 2009-04-02 at 21:19 +0300, Heikki Linnakangas wrote: The data type itself is quite trivial. It's all the operators that are more difficult to implement, and also immensely useful. That part is still incomplete. Can you please let me know what you find lacking (note: the SVN repo is the most current one)? I've implemented a pretty standard set of operators, and a GiST opclass to make things like overlaps, etc., indexable. I have not yet implemented temporal join. I'd recommend a book called Temporal Data and the Relational Model by C.J. Date, Hugh Darwen and Nikos Lorentzos for anyone interested in this topic. That book gives a guideline on how the data type and operators should behave. Agreed! That is a _very_ good book, and it's what I based my PERIOD type on (I used to call it t_interval because I agree with Date that's a better word -- but the conflict with SQL was too great so I changed it). I'd love to see that implemented. I volunteer to mentor if someone wants to tackle it. A big open question is whether we do new syntax, and if so, what. A lot of the literature for temporal types out there (from people basing their suggestions on SQL, like Snodgrass, et al., not C.J. Date) suggests syntax extensions which seem pretty specialized and unnecessary to me, but perhaps convenient. The only thing I really think needs better syntax is a constructor that can easily represent [ ), [ ], ( ), ( ] -- i.e. inclusive/exclusive. Right now I have 4 functions to do that, but it's awkward and overly verbose. In a related topic, an index that can implement a non-overlapping constraint is important to temporal databases. I have done some implementation work on this already, based on my proposal here: http://archives.postgresql.org//pgsql-hackers/2008-06/msg00404.php and I have adjusted my design to address some of the concerns Tom brings up here: http://archives.postgresql.org//pgsql-hackers/2008-06/msg00427.php I already have some code written, so if anyone else is thinking of working on this please contact me first. I will post my progress in the next couple weeks. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] Mentors needed urgently for SoC PostgreSQL Student Internships
Jeff Davis wrote: On Thu, 2009-04-02 at 21:19 +0300, Heikki Linnakangas wrote: The data type itself is quite trivial. It's all the operators that are more difficult to implement, and also immensely useful. That part is still incomplete. Can you please let me know what you find lacking (note: the SVN repo is the most current one)? I've implemented a pretty standard set of operators, and a GiST opclass to make things like overlaps, etc., indexable. I have not yet implemented temporal join. That, and temporal union and difference. You have a union operator, but that's not enough for a temporal union, as in: SELECT 'foo', (10, 20) as when UNION temporal on when -- imaginary syntax.. SELECT 'foo', (15, 30) as when - 'foo', (10, 30) Also, it would be nice to generalize the thing so that it works not only with intervals of time, but also floats, integers, numerics etc. The concept of an interval is not really tied to timestamps, even though that's probably the most common use case in the business world. I'd love to see that implemented. I volunteer to mentor if someone wants to tackle it. A big open question is whether we do new syntax, and if so, what. A lot of the literature for temporal types out there (from people basing their suggestions on SQL, like Snodgrass, et al., not C.J. Date) suggests syntax extensions which seem pretty specialized and unnecessary to me, but perhaps convenient. I can't imagine how you would implement temporal joins and unions without syntax extensions. If there is a way, that would be great, because that might allow us to implement them without backend changes. The only thing I really think needs better syntax is a constructor that can easily represent [ ), [ ], ( ), ( ] -- i.e. inclusive/exclusive. Right now I have 4 functions to do that, but it's awkward and overly verbose. Can't the input function handle those? Or you could have just one constructor with an extra argument indicating whether each end of the range is exclusive or inclusive. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] Mentors needed urgently for SoC PostgreSQL Student Internships
On Thu, 2009-04-02 at 21:58 +0300, Heikki Linnakangas wrote: I have not yet implemented temporal join. That, and temporal union and difference. You have a union operator, but that's not enough for a temporal union, as in: Ok, so you were talking about the relational operators, not interval predicates or interval operators. I agree that the relational operators are non-trivial. Also, it would be nice to generalize the thing so that it works not only with intervals of time, but also floats, integers, numerics etc. The concept of an interval is not really tied to timestamps, even though that's probably the most common use case in the business world. Yeah. I thought about how to do that with typmod, but it doesn't allow storing an entire OID for the constituent types. It may be possible to work around that. A big open question is whether we do new syntax, and if so, what. A lot of the literature for temporal types out there (from people basing their suggestions on SQL, like Snodgrass, et al., not C.J. Date) suggests syntax extensions which seem pretty specialized and unnecessary to me, but perhaps convenient. I can't imagine how you would implement temporal joins and unions without syntax extensions. If there is a way, that would be great, because that might allow us to implement them without backend changes. I still didn't know you were talking about relational operators at that point. Temporal join, union, difference, and also probably table logs all require syntax (not require maybe, but it would help a lot). The unnecessary syntax I was referring to is the SQL-ish syntax suggested by Snodgrass, et al, which involves words for things like overlaps, which we really don't need. The only thing I really think needs better syntax is a constructor that can easily represent [ ), [ ], ( ), ( ] -- i.e. inclusive/exclusive. Right now I have 4 functions to do that, but it's awkward and overly verbose. Can't the input function handle those? Or you could have just one constructor with an extra argument indicating whether each end of the range is exclusive or inclusive. Constructing from a single string is easy. What happens when you want to say ( 2009-01-01, now() ], or pass a timestamptz from a table? Ideas welcome. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] Mentors needed urgently for SoC PostgreSQL Student Internships
On Thu, Apr 2, 2009 at 2:58 PM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: Also, it would be nice to generalize the thing so that it works not only with intervals of time, but also floats, integers, numerics etc. The concept of an interval is not really tied to timestamps, even though that's probably the most common use case in the business world. Suddenly this thread has my undivided attention. A does-not-overlap operator would be awesome. A does-not-overlap index on a column whose value is a range would be awesome beyond words. As a simple example, consider an application whose job is to allocate subnets out of some larger IP block. Today, I typically handle cases of this type by defining triggers that generate the ends of the range and all the intermediate values and insert them into a side table with a unique index. It's really the pits, and unworkable for large ranges. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] Mentors needed urgently for SoC PostgreSQL Student Internships
All, Please: A. Stop cc'ing this thread to the WWW list. B. Please change the topic of this thread to Duration or Time types. --Josh Berkus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] Mentors needed urgently for SoC PostgreSQL Student Internships
On Mar 25, 2009, at 2:39 PM, Josh Berkus wrote: Note that since the Internships are not required to be project code, we can also take student projects to contribute to our WWW infrastructure and other areas the project needs some work. God, could someone do the module thing? :- I'd be happy to mentor in whatever way my limited knowledge would help. I wouldn't be of much help to someone working on backend code, however. Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
