RCS file: /usr/local/cvsroot/pgsql/src/backend/parser/gram.y,v
Working file: gram.y
head: 2.167
branch:
locks: strict
access list:
symbolic names:
	REL6_5_PATCHES: 2.88.0.2
	REL6_5: 2.88
	REL6_4: 2.37.0.2
	release-6-3: 2.5
	REL2_0B: 1.20.0.2
	REL2_0: 1.20
	Release_2_0_0: 1.7
	Release_1_0_3: 1.2.0.2
	Release_2_0: 1.6
	Release_1_0_2: 1.2
	PG95-1_01: 1.1.1.1
	PG95_DIST: 1.1.1
keyword substitution: kv
total revisions: 283;	selected revisions: 1
description:
----------------------------
revision 2.100
date: 1999/09/28 04:34:44;  author: momjian;  state: Exp;  lines: +9 -3
   I have been working with user defined types and user defined c
functions.  One problem that I have encountered with the function
manager is that it does not allow the user to define type conversion
functions that convert between user types. For instance if mytype1,
mytype2, and mytype3 are three Postgresql user types, and if I wish to
define Postgresql conversion functions like

I run into problems, because the Postgresql dynamic loader would look
for a single link symbol, mytype3, for both pieces of object code.  If
I just change the name of one of the Postgresql functions (to make the
symbols distinct), the automatic type conversion that Postgresql uses,
for example, when matching operators to arguments no longer finds the
type conversion function.

The solution that I propose, and have implemented in the attatched
patch extends the CREATE FUNCTION syntax as follows. In the first case
above I use the link symbol mytype2_to_mytype3 for the link object
that implements the first conversion function, and define the
Postgresql operator with the following syntax

The patch includes changes to the parser to include the altered
syntax, changes to the ProcedureStmt node in nodes/parsenodes.h,
changes to commands/define.c to handle the extra information in the AS
clause, and changes to utils/fmgr/dfmgr.c that alter the way that the
dynamic loader figures out what link symbol to use.  I store the
string for the link symbol in the prosrc text attribute of the pg_proc
table which is currently unused in rows that reference dynamically
loaded
functions.


Bernie Frankpitt
=============================================================================