Thanks to visit codestin.com
Credit goes to postgrespro.com

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

[email protected] (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