Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Enum type emulation: problem with opaque type in PL/pgSQL functions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Max Fonin <fonin(at)ziet(dot)zhitomir(dot)ua>
Cc: pgsql-general(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] Enum type emulation: problem with opaque type in PL/pgSQL functions
Date: 2000-11-24 16:37:34
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-generalpgsql-hackers
Max Fonin <fonin(at)ziet(dot)zhitomir(dot)ua> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>>> I guess the problem is that PL/pgSQL doesn't handle opaque type correctly.
>> No it doesn't, which is not surprising considering that opaque isn't
>> really a type at all.  The error message could be improved though :-(

> Well, I understood that the C is the only way very quick.
> Really, OPAQUE is just reference type like char* or void*, isn't it ?

No, it isn't a type at all.  Opaque really means, in essence, that
you're not saying what the function's arguments or result are.

There are several reasons for handling datatype I/O routines that way:

1. The actual argument types include C strings, which aren't an SQL

2. The I/O routines for a new type have to be defined before you can
say CREATE TYPE, and thus they can't name their true input or result
type anyway.

3. We have some "generic" I/O routines like array_in and array_out,
which work for multiple datatypes and so can't be declared as taking
any specific datatype.

BTW, the existing declarations of I/O routines for built-in types are
pretty messy and inconsistent (in particular, a lot of them are declared
to take or return int4 when they do no such thing).  This could be
cleaned up somewhat if we invented an SQL type name for "C string",
but I don't see any way around the other two points.

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2000-11-24 17:02:33
Subject: Re: Re: re : PHP and persistent connections
Previous:From: Giuseppe Tanzilli - CSFDate: 2000-11-24 15:49:05
Subject: Fields Case problem

pgsql-general by date

Next:From: David ReidDate: 2000-11-24 16:41:47
Subject: Curreny symbol
Previous:From: Peter EisentrautDate: 2000-11-24 16:07:42
Subject: Re: SV: Table whose name has Capital letters

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group