Tom Lane wrote:
Tim Allen <tim@xxxxxxxxxxxxxxxx> writes:
Don Y wrote:
So, I'll deploy them and get feedback on which features I
may need to add (some of the data types are probably a bit
too exotic for most users). I figure I can always contribute
them just before a release...
Just before a release would actually be a bad time to contribute the
code, if you want to get it accepted into PostgreSQL, as the people who
would be competent to review and potentially accept it all tend to be
very busy just before a release.
Yeah, I was about to make the same remark. The other thing we see over
and over is that once some idea or code sees the light of day, there are
almost always some better ideas offered by someone in the community, and
thus you need to budget some time for rework in response to comments.
If you're thinking of contributing something major for PG 8.2 (feature
freeze this July) it's already very late to not have at least a complete
design out there for public comment.
Note this is losing sight of my original question(s):
Is it possible to have one of my user defined data types
reviewed/critiqued to see if there are things that I am
not doing properly? Or, other things that I should be
including?
In that light, the idea of:
let it run in production for a few months; that will find
far more *realistic* issues than a casual inspection would!
makes perfect sense! I am assuming folks want contributed
code that 1) has been through some significant testing and
2) has been *evaluated* in a real-world environment to find
which features are missing or clumsy. His point (my associate)
is that those of us *needing* these data types are more likely
to find these problems than someone casually reviewing the
code or "playing" with it in a toy environment.
I assumed that the contents of ./contrib have NOT been
thoroughly tested/reviewed by the Postgres team (though
that is just an impression I have... i.e. why have those
features not been INTEGRATED into the codebase?)
