[EMAIL PROTECTED] (D'Arcy J.M. Cain) writes:
> It gets to fmgr_oldstyle() and then dies from a jump to a null pointer.
> Can someone please tell me how to make my function a newstyle one.
Perhaps you forgot the PG_FUNCTION_INFO_V1 declaration? See
http://www.ca.postgresql.org/users-lounge/docs/7
[EMAIL PROTECTED] (D'Arcy J.M. Cain) writes:
> Yah, I was looking at chapter 22 on SPI programming. I assume that the
> same should apply there. Shall I go ahead and add it to the docs in that
> chapter as well?
Uh ... where? I see nothing related to trigger programming in chapter 22.
There's
[EMAIL PROTECTED] (D'Arcy J.M. Cain) writes:
>> There's an example of an old-style function at
>> http://www.ca.postgresql.org/users-lounge/docs/7.1/postgres/spi-examples.html
>> but it's not a trigger.
> Ah. So PG_FUNCTION_INFO_V1() is strictly for triggers then.
No, it's for new-style functio
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > 2) check if the status of handle returned PQsetdbLogin is
> >CONNECTION_BAD closePGconn. if so, do not call pqPuts (and
> >pqFlush)
>
> I like this approach. The other way, you'd have to be sure that all
> failure paths close the socket befo
> So, may by add to pg_opclass two fields?
> bool is_varlena_key
> bool is_lossy_compress
Those are both properties of the compress function, the index method or the key type.
I do not think it has anything to do with operator classes (comparison functions),
and thus would be wrong in pg_opclas
