From: | Bill Studenmund <wrstuden(at)netbsd(dot)org> |
---|---|
To: | Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, <pgsql-hackers(at)postgreSQL(dot)org>, Fernando Nasser <fnasser(at)redhat(dot)com> |
Subject: | Re: RFD: schemas and different kinds of Postgres objects |
Date: | 2002-01-23 23:47:55 |
Message-ID: | Pine.NEB.4.33.0201231535590.7050-100000@vespasia.home-net.internetconnect.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 23 Jan 2002, Stephan Szabo wrote:
> On Wed, 23 Jan 2002, Bill Studenmund wrote:
>
> > On Wed, 23 Jan 2002, Tom Lane wrote:
> >
> > There is a third behavior which is almost the first one. And it's the one
> > I use for function matching in the package diffs I made oh so long ago.
> > :-)
> >
> > You look in the first namespace for all candidates. If one matches, you
> > use it. If two or more match, you throw the error we throw now. If none
> > match, you move on to the next namespace and repeat the search there.
>
> That's even more strongly towards earlier namespaces than my suggestion.
> How do you define match? If you allow coercions, then the
> plus(int8, int8) in my schema would be prefered over better (possibly
> exact) matches in the system schema which may not be what you want.
True. But:
1) How often are you going to make routines with names that duplicate
those in the system schema, when you don't want them to be used?
2) you can always explicitly refer to the system schema, so you can get
the routine you want if it's not the one you'll get by coercion.
3) We tested other (commercial) databases, and they have this behavior, so
it seems a reasonable thing to do.
4) It's simple and easy to understand.
Take care,
Bill
From | Date | Subject | |
---|---|---|---|
Next Message | Justin Clift | 2002-01-23 23:50:52 | PostgreSQL crashes with Qmail-SQL |
Previous Message | Mikheev, Vadim | 2002-01-23 23:39:16 | Re: Theory about XLogFlush startup failures |