Tom Lane wrote:
> Tim Allen <tim@proximity.com.au> 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?)
