Re: Using substr with user defined types - Mailing list pgsql-sql

From Tom Lane
Subject Re: Using substr with user defined types
Date
Msg-id 23390.958661577@sss.pgh.pa.us
Whole thread Raw
In response to Re: Using substr with user defined types  (darcy@druid.net (D'Arcy J.M. Cain))
Responses Re: Using substr with user defined types  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: Using substr with user defined types  (darcy@druid.net (D'Arcy J.M. Cain))
List pgsql-sql
darcy@druid.net (D'Arcy J.M. Cain) writes:
> create function chkpass_rout(opaque)
>     returns opaque
>     as '/usr/pgsql/modules/chkpass.so'
>     language 'c';

> Here is what happens.

> soccer=> select chkpass_rout('hello'::chkpass);
> ERROR:  typeidTypeRelid: Invalid type - oid = 0

Functions that you intend to invoke as ordinary functions shouldn't have
inputs or outputs declared "opaque", because the expression evaluation
code won't have any idea what to do.  When you are building functions
that will be the input or output converters for a datatype, you can read
"opaque" as meaning "C string", so for example the input converter takes
opaque and returns your type.  But otherwise you don't want to be using
opaque.  Perhaps what you wanted here was
"create function chkpass_rout(chkpass) returns text".

I'd like to see "opaque" eliminated from Postgres, because it's
unhelpfully named and is used to cover several distinct purposes that
would be better served with distinct names.  Might create too much of
a backwards compatibility problem though :-(
        regards, tom lane


pgsql-sql by date:

Previous
From: Tom Lane
Date:
Subject: Re: translate from oracle
Next
From: Tom Lane
Date:
Subject: Re: Foreign keys and access privileges