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

Re: search_path vs extensions

From: Greg Stark <stark(at)enterprisedb(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "David E(dot) Wheeler" <david(at)kineticode(dot)com>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, Stephen Frost <sfrost(at)snowman(dot)net>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Josh Berkus <josh(at)agliodbs(dot)com>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
Subject: Re: search_path vs extensions
Date: 2009-05-29 21:45:14
Message-ID: 4136ffa0905291445m46c34dc1j192b94e37fa38647@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Fri, May 29, 2009 at 10:26 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> This sounds quite horrid to me.  The way programming languages solve
> this problem is they have a flag that either makes certain names not
> visible from other namespaces, or they provide explicit control over
> which names get exported.

There are two factors which distinguish this situation from most
programming languages:

1) Hopefully these languages you're thinking of are lexically scoped.
So the search path in effect when the objects are defined decide which
other objects they reference. In Postgres in many cases we're
effectively dynamically scoped. If someone calls us with another
search path we'll pick up other objects we weren't expecting.

2) Normally programming languages do early binding so as soon as the
code is parsed references are resolved. You can't later define a new
function earlier in the search path and have it take over references
that have were previously referring to some other function.

> Requiring the extension author to split up
> the objects between two different hard-coded namespaces with schema
> qualifications on every reference sounds like an unmanageable mess.

Well I think the thinking is that if the extension author wants to
hide some objects from the public he creates a schema for them and
references them explicitly.

If he pushes that private schema onto the search path he'll find any
functions he calls -- admittedly not that common since we don't have
any way to do callbacks, i suppose triggers on tables his code
modifies counts though -- will have this private schema in its search
path...

If we do want special handling it does seem to me that it would make
sense to have some token like _private_ which the extension loading
mechanism would automatically substitute for a unique schema name.
Otherwise we're relying on extension authors to come up with unique
names.



-- 
greg

In response to

Responses

pgsql-hackers by date

Next:From: Hannu KrosingDate: 2009-05-29 21:47:16
Subject: Re: bytea vs. pg_dump
Previous:From: Hannu KrosingDate: 2009-05-29 21:43:20
Subject: Re: bytea vs. pg_dump

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