Re: RFD: schemas and different kinds of Postgres objects - Mailing list pgsql-hackers

From Mike Mascari
Subject Re: RFD: schemas and different kinds of Postgres objects
Date
Msg-id 3C4E0EB1.1E3687FD@mascari.com
Whole thread Raw
In response to Re: RFD: schemas and different kinds of Postgres objects  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
Tom Lane wrote:
> 
> I'm particularly troubled by the idea of trying to apply this "any"
> lookup concept to resolution of overloaded operators and functions.
> Suppose I have a reference func(type1,type2) that I'm trying to resolve,
> and I have an inexact match (one requiring coercion) in my own schema.
> Do I look to the "any" schema to see if there are better matches?
> If so, what happens if the "any" schema contains multiple possibilities
> with identical signatures (presumably created by different users)?  ISTM
> this will positively guarantee a resolution failure, since there's no
> way for the resolver to prefer one over another.  Thus, by creating
> a "func(foo,bar)" function --- quite legally --- JRandomLuser might
> break other people's formerly working queries that use other functions
> named func.  Although it's possible for this to happen now, it'll be
> a lot more surprising if JRandomLuser thinks that his functions live
> in his own private schema namespace.
>

So, in a nutshell, the price we pay for function overloading is the
inability to have schema-specific functions. Right? Possibly why Oracle
doesn't allow function overloading? As a user, I'd much rather have
schema-specific functions than only global. I'm not downplaying the
value of function overloading, but if I had the choice (which I guess I
can't/won't), I'd choose schema-specific functions over function
overloading...

Mike Mascari
mascarm@mascari.com


pgsql-hackers by date:

Previous
From: "Ross J. Reedstrom"
Date:
Subject: Re: Cross posting
Next
From: Bill Studenmund
Date:
Subject: Re: RFD: schemas and different kinds of Postgres objects