From: | "Rod Taylor" <rbt(at)zort(dot)ca> |
---|---|
To: | <pgsql-hackers(at)postgresql(dot)org>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: Operators and schemas |
Date: | 2002-04-15 19:51:48 |
Message-ID: | 097d01c1e4b6$fb0c9090$8001a8c0@jester |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> 2. Use a restricted, perhaps fixed search-path for searching for
> operators. For example, we might force the search path to have
> pg_catalog first even when this is not true for the table name
search
> path. But I'm not sure what an appropriate definition would be.
> A restricted search path might limit the usefulness of private
operators
> to the point where we might as well have kept them database-wide.
Wanting to open a bucket of worms, what would making the system create
an operator with the schema name in it?
Ie. Create operator schema.+ would create:
'schema.+' in pg_catalog
'+' in schema
This would require double the operator entries, but isn't really any
worse than the array types as related to their base type.
So, user could type:
select col1 + col2 from schema.tab;
select col1 schema.+ col2 from tab;
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2002-04-15 19:54:03 | Re: Operators and schemas |
Previous Message | Tom Lane | 2002-04-15 19:24:20 | Re: Inefficient handling of LO-restore + Patch |