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

Re: [HACKERS] regproc fix

From: "Thomas G(dot) Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu>
To: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
Cc: hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] regproc fix
Date: 1998-10-02 15:23:48
Message-ID: 3614F004.FC641A6F@alumni.caltech.edu (view raw or flat)
Thread:
Lists: pgsql-hackers
> > > One remaining problem is that you have to supply the oid in 
> > > quotes, because regproc has to get a string, not an int.  Perhaps 
> > > we need another regprocin that allows int4 or char*, but I don't 
> > > think you can allow two input functions for a type.
> > > Perhaps we can just leave it.  We also output the proname, even if
> > > they used the oid as input.
> > The int4 vs. string issue would be easily solved by having a routine
> > regproc(int4), which the new type coersion stuff would use
> > automatically.
> I started coding it, but realized that things like CREATE FUNCTION 
> will still be looking for a string for the input function, so we would 
> have to change those too.  Does not seem worth the confusion.

Well, I've been really confused through this whole issue, so I'm used to
it :)

If everything works the way you want, but you would like to be able to
enter OID-style regproc names using integer conventions as well as using
string conventions, then defining this extra routine will let you do
that. No other changes, no changes to input/output routines, nada.
CREATE FUNCTION, if it works now, would continue to work; everything
else stays the same. The default behavior of handling regproc OID
identifiers as strings seems fine if it does what you need. This would
just give a user additional flexibility in how they specify regprocs for
input.

                      - Tom

In response to

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 1998-10-02 15:31:43
Subject: Re: [HACKERS] regproc fix
Previous:From: Bruce MomjianDate: 1998-10-02 15:22:27
Subject: Re: [HACKERS] spinlock code for ns32k (again)

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