Re: [HACKERS] Mentors needed urgently for SoC & PostgreSQL Student Internships

All,

Due to budget constraints, Google needed to cut 50 projects from the
Summer of Code this year. We were one of the projects cut (although we
can re-apply next year).

However, that doesn't mean we won't be working with students this year.

1) Portland State University has generously offered to host 1 or 2
PostgreSQL-based projects in their GSoC compliment.

2) We can fund two student internships our of PostgreSQL money. This
would also allow us to fund some projects which don't fit within the
parameters of GSoC (wrong schedule, high school student, docs or
infrastructure rather than code, etc.).

What this all hinges on is getting some really solid mentors who have
projects they'd like students to work on, and can commit unconditionally
to having 5 hours a week or more, over a 3-month period, to work with
the student.

If we don't get at least 4 solid mentor-volunteers by next week, I'll
drop the whole idea and we'll stop doing internships or SoC entirely.

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.

--Josh Berkus
for the Core Team

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

Ciao Josh,

Josh Berkus ha scritto:
> What this all hinges on is getting some really solid mentors who have
> projects they'd like students to work on, and can commit
> unconditionally to having 5 hours a week or more, over a 3-month
> period, to work with the student.
Thanks for letting us know. However for this year we (as 2ndQuadrant)
have just planned to collaborate with some Italian Universities,
starting from the University of Pisa (I spoke to their IT students last
Monday). I don't think we can dedicate more time to mentoring in the
short period (that's a pity, I know). :(

However, thanks again for keeping us informed.

Ciao,
Gabriele

--
Gabriele Bartolini - 2ndQuadrant Italia
PostgreSQL Training, Services and Support
gabriele(dot)bartolini(at)2ndQuadrant(dot)it | www.2ndQuadrant.it

> Due to budget constraints, Google needed to cut 50 projects from the
> Summer of Code this year. We were one of the projects cut (although we
> can re-apply next year).

Leslie at Google has asked me to clarify this. We *also* made a mistake
on our application which disqualified us.

--Josh

On Mar 29, 2009, at 10:08 PM, Josh Berkus wrote:

>
>> Due to budget constraints, Google needed to cut 50 projects from the
>> Summer of Code this year. We were one of the projects cut (although
>> we
>> can re-apply next year).
>
> Leslie at Google has asked me to clarify this. We *also* made a
> mistake on our application which disqualified us.

What mistake was that??

D

>> 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 Lembark 85-09 90th St.
Workhorse Computing Woodhaven, NY, 11421
lembark(at)wrkhors(dot)com +1 888 359 3508

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

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

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

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

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

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

On Thu, Apr 2, 2009 at 2:58 PM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)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

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