Re: [HACKERS] Seeking Google SoC Mentors
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Well, here's a question. Given the recent discussion re full disjunction, I'd like to know what sort of commitment we are going to give people who work on proposed projects. Um, if you mean are we going to promise to accept a patch in advance of seeing it, the answer is certainly not. Still, a SoC author can improve his chances in all the usual ways, primarily by getting discussion and rough consensus on a spec and then on an implementation sketch before he starts to do much code. Lots of showstopper problems can be caught at that stage. We cannot necessarily expect the students to work this way without guidance if they are not familiar with our processes before they start. The mentors should be there to guide not just with the technical aspects of the project, but the procedural as well imho. Regards, Dave ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Seeking Google SoC Mentors
On Tue, Feb 27, 2007 at 09:21:42AM +, Dave Page wrote: Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Well, here's a question. Given the recent discussion re full disjunction, I'd like to know what sort of commitment we are going to give people who work on proposed projects. Um, if you mean are we going to promise to accept a patch in advance of seeing it, the answer is certainly not. Still, a SoC author can improve his chances in all the usual ways, primarily by getting discussion and rough consensus on a spec and then on an implementation sketch before he starts to do much code. Lots of showstopper problems can be caught at that stage. We cannot necessarily expect the students to work this way without guidance if they are not familiar with our processes before they start. The mentors should be there to guide not just with the technical aspects of the project, but the procedural as well imho. IIRC, last time we had a pgsql-students (or similar) mailinglist for the SoC people. That was closed. Perhaps that's a bit counterproductive - it's better to get introduced to the normal way of doing things right away? With the help of the mentor, of course. //Magnus ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Seeking Google SoC Mentors
Magnus Hagander wrote: On Tue, Feb 27, 2007 at 09:21:42AM +, Dave Page wrote: Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Well, here's a question. Given the recent discussion re full disjunction, I'd like to know what sort of commitment we are going to give people who work on proposed projects. Um, if you mean are we going to promise to accept a patch in advance of seeing it, the answer is certainly not. Still, a SoC author can improve his chances in all the usual ways, primarily by getting discussion and rough consensus on a spec and then on an implementation sketch before he starts to do much code. Lots of showstopper problems can be caught at that stage. We cannot necessarily expect the students to work this way without guidance if they are not familiar with our processes before they start. The mentors should be there to guide not just with the technical aspects of the project, but the procedural as well imho. IIRC, last time we had a pgsql-students (or similar) mailinglist for the SoC people. That was closed. Perhaps that's a bit counterproductive - it's better to get introduced to the normal way of doing things right away? With the help of the mentor, of course. Yes. The other issue though is that initial project proposal scoring and discussion is done on a private Google site by the mentors. I don't know if we're allowed to make the proposals public before they get accepted by Google in case the students copy or improve each others proposals. From their (and Google's) point of view their proposals are essentially job applications. Once they've been ranked, and Google have approved the top-N projects I guess it's open season! Regards, Dave ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Seeking Google SoC Mentors
On Tue, Feb 27, 2007 at 09:53:41AM +, Dave Page wrote: Magnus Hagander wrote: On Tue, Feb 27, 2007 at 09:21:42AM +, Dave Page wrote: Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Well, here's a question. Given the recent discussion re full disjunction, I'd like to know what sort of commitment we are going to give people who work on proposed projects. Um, if you mean are we going to promise to accept a patch in advance of seeing it, the answer is certainly not. Still, a SoC author can improve his chances in all the usual ways, primarily by getting discussion and rough consensus on a spec and then on an implementation sketch before he starts to do much code. Lots of showstopper problems can be caught at that stage. We cannot necessarily expect the students to work this way without guidance if they are not familiar with our processes before they start. The mentors should be there to guide not just with the technical aspects of the project, but the procedural as well imho. IIRC, last time we had a pgsql-students (or similar) mailinglist for the SoC people. That was closed. Perhaps that's a bit counterproductive - it's better to get introduced to the normal way of doing things right away? With the help of the mentor, of course. Yes. The other issue though is that initial project proposal scoring and discussion is done on a private Google site by the mentors. I don't know if we're allowed to make the proposals public before they get accepted by Google in case the students copy or improve each others proposals. From their (and Google's) point of view their proposals are essentially job applications. Right. We'll just have to live by Googles rule for that part, I'm talking about the discussions later. Once things are approved, they should all be handled on the standard mailinglists, IMHO. Being able to make possibly controversial suggestiosn public beforehand would certainly help, but may not be possible. But aren't we supposed to pick mentors who will know enough to be able to make that call themselves? //Magnus ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Seeking Google SoC Mentors
Magnus Hagander wrote: Right. We'll just have to live by Googles rule for that part, I'm talking about the discussions later. Once things are approved, they should all be handled on the standard mailinglists, IMHO. Oh, 100% agreed. Being able to make possibly controversial suggestiosn public beforehand would certainly help, but may not be possible. But aren't we supposed to pick mentors who will know enough to be able to make that call themselves? yeah, in theory, but you know how wildly opinions can vary even amongst the oldest and most familiar of community members. Regards, Dave ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Seeking Google SoC Mentors
On Tue, Feb 27, 2007 at 12:47:14AM -0500, Tom Lane wrote: Jim C. Nasby [EMAIL PROTECTED] writes: Yes, but the list being discussed is SoC projects that the community would like to see done, which means most people would assume that #1 isn't an issue. We need to make sure that every project on the list of SoC ideas is supported by the community. Agreed, except that in most cases a one-liner description of an idea isn't enough to get a meaningful reading on whether people think it's sane or not. To take our current example: do you think a one-liner description of full disjunctions would have gotten any feedback, except for requests for more detail? I'm not sure how we fix that --- laying out every acceptable project in great detail in advance won't happen for lack of manpower, and wouldn't be a good idea even if we could do it, because that sounds like a great way to stifle creativity. At the same time we can hardly promise to accept every wild-west idea that someone manages to turn into some kind of code. What can we tell the students other than get as much feedback as you can, as early as you can? I agree we certainly don't want to go designing these projects in advance, but I think we could at least ensure that the community buys into the concept of each project. ISTM one of the big issues with FD is that most people didn't even really understand what exactly it was or how it might be useful, which made getting broad acceptance even harder. For example, these TODOs seem like they have good acceptance by the community (though they might not be good SoC projects for other reasons): Simplify ability to create partitioned tables Allow auto-selection of partitioned tables for min/max() operations Allow commenting of variables in postgresql.conf to restore them to defaults Examples of ideas that might not be good because it's unclear that the community supports them: Stop-on-a-dime partial vacuum Adding a replication solution to the backend Putting time travel support back in Granted, the 'not good idea' list is pretty exaggerated simply because it's not as easy to find examples of that on the TODO list, since stuff on the TODO list is generally supported. Some of the 'temporal database' items that had been suggested probably fall into the category of 'might be a good idea, but the community hasn't decided that yet'. So maybe we should be limiting SoC projects to stuff that's already on the TODO list.. -- Jim Nasby[EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Seeking Google SoC Mentors
Well, the HOT discussion hasn't yet led to an accepted patch ... and I'd say its authors still did way too much work before getting the community involved. But certainly it's a better model to look at than what the FD author did. That's pretty much the mentor's job. I don't remember who mentored FD, but obviously there wasn't enough guidance. -- Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Seeking Google SoC Mentors
On Monday 26 February 2007 18:46, Josh Berkus wrote:
Demian,
Could you also please share your thoughts on what would be a good
student profile- for instance, how much theoretical background and
practical experience, for working on a SoC project?
Well, it shouldn't be the student's first year writing code. Basically,
they're committing to developing a feature *to completion* in 3 months.
We're going to be evaluating proposals based on whether we think students
can do that.
References of some kind will be important, given that we'll only be
accepting about 12% of proposals. So, some demonstration of the student's
ability to code from either the open source world or previous coursework.
I don't know, honestly, that we care very much about theoretical
background, except where it relates directly to and cutting-edge concepts
in you proposal. PostgreSQL-space is littered with half-completed
academic projects; we're not seeking more of those.
Additionally it doesn't hurt to bring up an idea to the community before you
even submit the application. If you get buy in / agreement from multiple
community members on a project now, it can only help your chances in the SoC
process. (Picking items from the TODO list is a good way to start if you need
ideas)
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] Seeking Google SoC Mentors
Jim C. Nasby wrote: I agree we certainly don't want to go designing these projects in advance, but I think we could at least ensure that the community buys into the concept of each project. Yes, at least for those that go on a suggestion list. And that was my worry about Warren's suggestion - I haven't seen much enthusiasm for it from anyone else, so the degree of in-principle buyin is fairly dubious. cheers andrew ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Seeking Google SoC Mentors
On Tue, Feb 27, 2007 at 10:49:18AM -0600, Jim C. Nasby wrote: I agree we certainly don't want to go designing these projects in advance, but I think we could at least ensure that the community buys into the concept of each project. ISTM one of the big issues with FD is that most people didn't even really understand what exactly it was or how it might be useful, which made getting broad acceptance even harder. I think it might be useful to at least encourage people wanting to an SoC project to create page on the developer wiki selling their idea. You know, questions like: why do we want it? Where do you expect it to be included? etc. That might help catch misunderstandings much earlier. Have a nice day, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ From each according to his ability. To each according to his ability to litigate. signature.asc Description: Digital signature
Re: [HACKERS] Seeking Google SoC Mentors
Martijn van Oosterhout wrote: I think it might be useful to at least encourage people wanting to an SoC project to create page on the developer wiki selling their idea. You know, questions like: why do we want it? Where do you expect it to be included? etc. They are expected to do as much when they apply for a project at the Google site. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Seeking Google SoC Mentors
Josh Berkus wrote: The next Summer of Code is just around the corner. Last year, we had 46 submissions and seven we accepted. Out of the SoC we got two ongoing contributors, several good patches, two code refactors and even an employee for a PostgreSQL company. I'd like to see us do the same this year! Therefore, we need volunteer mentors. Here's how it works: -- You help review and rate submissions in March. -- From May-August, you mentor one or two SoC students in working on PostgreSQL patches. This means that you must be readily available to your student(s) during this summer and have time (2-5 hours per week, more at the beginning) to coach them. -- You need to evaluate the student's progress both midsummer and on completion. -- You prepare the student code for submission as an 8.4 feature, if applicable. -- Around October, Google gives SPI $500 for your mentoring. You can choose to take this money (less transaction fees) or leave it as a donation. You also get a nifty t-shirt. We're looking for mentors who are: -- patient -- available -- knowledgeable in depth in some particular area/add-in to PostgreSQL -- interested in reviewing student code -- interested in helping create the next generation of contributors Particularly we'd like people who can mentor on: -- PostgreSQL internals -- GIS -- applications client tools -- advanced indexing -- XML ... based on last year's submissions, but there will be more this year. Also, I am looking for contacts at universities where I can direct notices when SoC opens. E-mail me ASAP. Is there a list of projects? Or can we suggest some? cheers andrew ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Seeking Google SoC Mentors
Andrew, Is there a list of projects? Or can we suggest some? Suggest away, please! I'm going to update the website soon, would appreciate new content. -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Seeking Google SoC Mentors
On 2/26/07, Andrew Dunstan [EMAIL PROTECTED] wrote: Josh Berkus wrote: The next Summer of Code is just around the corner. Last year, we had 46 submissions and seven we accepted. Out of the SoC we got two ongoing contributors, several good patches, two code refactors and even an employee for a PostgreSQL company. I'd like to see us do the same this year! Therefore, we need volunteer mentors. Here's how it works: -- You help review and rate submissions in March. -- From May-August, you mentor one or two SoC students in working on PostgreSQL patches. This means that you must be readily available to your student(s) during this summer and have time (2-5 hours per week, more at the beginning) to coach them. -- You need to evaluate the student's progress both midsummer and on completion. -- You prepare the student code for submission as an 8.4 feature, if applicable. -- Around October, Google gives SPI $500 for your mentoring. You can choose to take this money (less transaction fees) or leave it as a donation. You also get a nifty t-shirt. We're looking for mentors who are: -- patient -- available -- knowledgeable in depth in some particular area/add-in to PostgreSQL -- interested in reviewing student code -- interested in helping create the next generation of contributors Particularly we'd like people who can mentor on: -- PostgreSQL internals -- GIS -- applications client tools -- advanced indexing -- XML ... based on last year's submissions, but there will be more this year. Also, I am looking for contacts at universities where I can direct notices when SoC opens. E-mail me ASAP. Is there a list of projects? Or can we suggest some? I'd like to suggest working on a patch testing tool that was discussed previously. :) Regards, Mark ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Seeking Google SoC Mentors
Josh Berkus wrote: Andrew, Is there a list of projects? Or can we suggest some? Suggest away, please! I'm going to update the website soon, would appreciate new content. here are a few ideas to be going on with (none of these are new): buildfarm: 1. Buildfarm web app: is in urgent need of renovation. (perl + postgres + template toolkit. might be nice to rework it as a Catalyst app). 2. Buildfarm client: support downloading patches from an approved server, doing apply, build, install, and test. (perl + maybe SOAP) 3. Buildfarm client + web app: support running performance tests and reporting on them (start with pgbench) (s/w as above) postgres core: 4. allow use of LIKE syntax in all type expressions e.g. select * from mysrf() as (label text, like foo); create type xx as (label text, like bar); cheers andrew ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Seeking Google SoC Mentors
On 2/26/07, Josh Berkus josh@agliodbs.com wrote: Andrew, Is there a list of projects? Or can we suggest some? Suggest away, please! I'm going to update the website soon, would appreciate new content. I can also volunteer to mentor continuing work on a TPC-E kit, for C stored procedures and improved results reporting. Mark ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Seeking Google SoC Mentors
On Monday 26 February 2007 14:22, Andrew Dunstan wrote: Is there a list of projects? Or can we suggest some? Temporal database support * base data types - verify current for ISO compliance (timestamp, interval) - implement period datatype * operators for those datatypes * add support for valid time tables * add support for transaction time tables * add support for bi-temporal tables Check out [1] for more info. [1]http://www.cs.arizona.edu/~rts/ wt -- Warren Turkal (w00t) ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Seeking Google SoC Mentors
Warren Turkal wrote: On Monday 26 February 2007 14:22, Andrew Dunstan wrote: Is there a list of projects? Or can we suggest some? Temporal database support * base data types - verify current for ISO compliance (timestamp, interval) - implement period datatype * operators for those datatypes * add support for valid time tables * add support for transaction time tables * add support for bi-temporal tables Well, here's a question. Given the recent discussion re full disjunction, I'd like to know what sort of commitment we are going to give people who work on proposed projects. I understand Warren's keenness for this, but it's not clear to me that it has lots of support elsewhere, and IIRC the idea was rejected by the SQL Standards body. I don't object to making new data types available, but new table properties is quite another matter. So, what exactly are we promising? cheers andrew ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Seeking Google SoC Mentors
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Could you also please share your thoughts on what would be a good student profile- for instance, how much theoretical background and practical experience, for working on a SoC project? Demian The next Summer of Code is just around the corner. Last year, we had 46 submissions and seven we accepted. Out of the SoC we got two ongoing contributors, several good patches, two code refactors and even an employee for a PostgreSQL company. I'd like to see us do the same this year! Therefore, we need volunteer mentors. Here's how it works: -- You help review and rate submissions in March. -- From May-August, you mentor one or two SoC students in working on PostgreSQL patches. This means that you must be readily available to your student(s) during this summer and have time (2-5 hours per week, more at the beginning) to coach them. -- You need to evaluate the student's progress both midsummer and on completion. -- You prepare the student code for submission as an 8.4 feature, if applicable. -- Around October, Google gives SPI $500 for your mentoring. You can choose to take this money (less transaction fees) or leave it as a donation. You also get a nifty t-shirt. We're looking for mentors who are: -- patient -- available -- knowledgeable in depth in some particular area/add-in to PostgreSQL -- interested in reviewing student code -- interested in helping create the next generation of contributors Particularly we'd like people who can mentor on: -- PostgreSQL internals -- GIS -- applications client tools -- advanced indexing -- XML ... based on last year's submissions, but there will be more this year. Also, I am looking for contacts at universities where I can direct notices when SoC opens. E-mail me ASAP. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFF4204Ws7G5iIp9akRAh6yAKCMp3Fy66BsPmsAGQ7i6CwavE2hFQCgoIZG 66zWJUCOweH0LCgQA9NpotA= =Ea5J -END PGP SIGNATURE- ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Seeking Google SoC Mentors
Demian, Could you also please share your thoughts on what would be a good student profile- for instance, how much theoretical background and practical experience, for working on a SoC project? Well, it shouldn't be the student's first year writing code. Basically, they're committing to developing a feature *to completion* in 3 months. We're going to be evaluating proposals based on whether we think students can do that. References of some kind will be important, given that we'll only be accepting about 12% of proposals. So, some demonstration of the student's ability to code from either the open source world or previous coursework. I don't know, honestly, that we care very much about theoretical background, except where it relates directly to and cutting-edge concepts in you proposal. PostgreSQL-space is littered with half-completed academic projects; we're not seeking more of those. -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Seeking Google SoC Mentors
Andrew Dunstan [EMAIL PROTECTED] writes: Well, here's a question. Given the recent discussion re full disjunction, I'd like to know what sort of commitment we are going to give people who work on proposed projects. Um, if you mean are we going to promise to accept a patch in advance of seeing it, the answer is certainly not. Still, a SoC author can improve his chances in all the usual ways, primarily by getting discussion and rough consensus on a spec and then on an implementation sketch before he starts to do much code. Lots of showstopper problems can be caught at that stage. I think the main problems with the FD patch were (1) much of the community was never actually sold on it being a useful feature, and (2) the implementation was not something anyone wanted to accept into core, because of its klugy API. Both of these points could have been dealt with before a line of code had been written, but they were not :-( regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Seeking Google SoC Mentors
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Well, here's a question. Given the recent discussion re full disjunction, I'd like to know what sort of commitment we are going to give people who work on proposed projects. Um, if you mean are we going to promise to accept a patch in advance of seeing it, the answer is certainly not. Still, a SoC author can improve his chances in all the usual ways, primarily by getting discussion and rough consensus on a spec and then on an implementation sketch before he starts to do much code. Lots of showstopper problems can be caught at that stage. Tom, Correct me if I am wrong, but would the way that HOT has been handled be a good way for the SoC people to do things? Joshua D. Drake I think the main problems with the FD patch were (1) much of the community was never actually sold on it being a useful feature, and (2) the implementation was not something anyone wanted to accept into core, because of its klugy API. Both of these points could have been dealt with before a line of code had been written, but they were not :-( regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Seeking Google SoC Mentors
Joshua D. Drake [EMAIL PROTECTED] writes: Correct me if I am wrong, but would the way that HOT has been handled be a good way for the SoC people to do things? Well, the HOT discussion hasn't yet led to an accepted patch ... and I'd say its authors still did way too much work before getting the community involved. But certainly it's a better model to look at than what the FD author did. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Seeking Google SoC Mentors
On Mon, Feb 26, 2007 at 09:10:38PM -0500, Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Well, here's a question. Given the recent discussion re full disjunction, I'd like to know what sort of commitment we are going to give people who work on proposed projects. Um, if you mean are we going to promise to accept a patch in advance of seeing it, the answer is certainly not. Still, a SoC author can improve his chances in all the usual ways, primarily by getting discussion and rough consensus on a spec and then on an implementation sketch before he starts to do much code. Lots of showstopper problems can be caught at that stage. I think the main problems with the FD patch were (1) much of the community was never actually sold on it being a useful feature, and (2) the implementation was not something anyone wanted to accept into core, because of its klugy API. Both of these points could have been dealt with before a line of code had been written, but they were not :-( Yes, but the list being discussed is SoC projects that the community would like to see done, which means most people would assume that #1 isn't an issue. We need to make sure that every project on the list of SoC ideas is supported by the community. -- Jim Nasby[EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Seeking Google SoC Mentors
Jim C. Nasby [EMAIL PROTECTED] writes: Yes, but the list being discussed is SoC projects that the community would like to see done, which means most people would assume that #1 isn't an issue. We need to make sure that every project on the list of SoC ideas is supported by the community. Agreed, except that in most cases a one-liner description of an idea isn't enough to get a meaningful reading on whether people think it's sane or not. To take our current example: do you think a one-liner description of full disjunctions would have gotten any feedback, except for requests for more detail? I'm not sure how we fix that --- laying out every acceptable project in great detail in advance won't happen for lack of manpower, and wouldn't be a good idea even if we could do it, because that sounds like a great way to stifle creativity. At the same time we can hardly promise to accept every wild-west idea that someone manages to turn into some kind of code. What can we tell the students other than get as much feedback as you can, as early as you can? regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
