Tom Lane wrote:
> Don Y <pgsql@DakotaCom.Net> writes:
>> Yeah, I was hoping someone would have built a template for
>> new types that trimmed everything down to a single page/file
>> instead of having to snoop the source tree. :-(
>
> The various new types in contrib/ are there in part to serve as models.
Yes, but they don't appear to be maintained. E.g., I had to stumble
on the proper usage of:
PG_FUNCTION_INFO_V1(foo)
Datum foo(PG_FUNCTION_ARGS)
PG_GETARG_*(#)
PG_RETURN_*(baz)
errdetail
ERRCODE_INVALID_TEXT_REPRESENTATION (vs. the error code used in
the contributed code)
In addition to requiring clarification of the questions posed
previously.
No big deal. But, it would have saved a little time and
gone a long way towards improving my confidence that my
first implementation would work "as is"...
Obviously, the goal is (should be?) to produce code that can
be contributed back "as is" without having someone spend time
tweeking it to fit the "right" way of doing things. :-/
I'll see what else I can learn in the remaining data types
that I have to build and then cobble together a template
or an article to hopefully make this a bit more straightforward
(at least so that it tells folks what information they need
to ferret out of man pages, etc.)
> You could also look on pgfoundry and gborg to see other examples.
Ah, haven't even poked around in those areas! Thnks!
--don