Re: Code for user-defined type

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Paul Jones <pbj(at)cmicdo(dot)com>
Cc: "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Code for user-defined type
Date: 2014-05-29 16:09:57
Message-ID: CAFj8pRD-k+6DsYbKCzU_CGLjT0v930xnp2pRwrfXM294rAF8gw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

2014-05-29 18:04 GMT+02:00 Paul Jones <pbj(at)cmicdo(dot)com>:

> On Wed, May 28, 2014 at 10:51:43AM +0200, Pavel Stehule wrote:
> >
> > Hello
> >
> >
> > 2014-05-27 20:30 GMT+02:00 Paul Jones <pbj(at)cmicdo(dot)com>:
> >
> > > I have written a user-defined type that allows direct import and
> printing
> > > of
> > > DB2 timestamps.It does correctly import and export DB2 timestamps,
> > > butI'm wondering ifsomeone could tell me if I made anymistakes in
> > > the C code, particularly w.r.t. memory leaks or non-portableconstructs.
> > >
> > >
> > > I'm doing this on 9.3.4.
> > >
> > > Thanks,
> >
> > There is one issue DirectFunctionCall takes a parameters converted to
> Datum
> > and returns Datum
> >
> > You should to use a macros XGetDatum and DatumGetX
> >
> > In this case
> >
> > newDate = DatumGetTimestamp(DirectFunctionCall2(to_timestamp,
> > CStringGetDatum(date_txt),
> > CStringGetDatum(cstring_to_text(nls_date_format))));
> >
> > PG_RETURN_TIMESTAMP(newDate);
> >
> >
> >
> > There is inconsistency in types - Timestamp and Timestamptz -
>
> Thanks, Pavel!
>
> I used the proper XGetDatum and DatumGetX and was able to get it to work
> properly. However, I since discovered that I probably should not use
> "cstring_to_text" because of the palloc's it does. The problem comes
> when doing "\copy table from file". After about 1000 rows, the backend
> dies with SEGV, I think because of too many pallocs being created in
> the copy transaction.
>
> I rewrote it so that the format string is turned into a text at .so load
> time,
> and then converted the input string into a local text.
>

too many pallocs should not fail on SEGV (I am thinking, but can be
fallible).

For extension development is good idea use postgres backend compiled with
--enable-cassert option.

It can do a extra tests of memery usage, and can show some other information

Regards

Pavel

>
> PJ
>

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Mimiko 2014-05-29 16:16:10 Re: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object
Previous Message Paul Jones 2014-05-29 16:04:40 Re: Code for user-defined type