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

search_path vs extensions

From: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: search_path vs extensions
Date: 2009-05-25 09:16:23
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers

  Preliminary note: I'm using the term "extension" as if it's what we
  already agree to call them, feel free to ignore this and use whatever
  term you see fit. We'll have the naming issue tackled, please not now

Following-up to discussions we had at the Developer Meeting and
subsequent pub events, I'd like us to agree upon the relations of
extensions and search_path. We basically have to choose one of those:

Proposal: do nothing
What's good about it:
  it's already there, folks!
What's not good about it:
  Users are alone on deciding where to put what, and the system won't
  help them: either public is a complete mess, or they have to manually
  care about search_path for their extensions and their own application
  needs. Installations where DBA and application folks are separate
  teams will suffer, ones where the application is heavily using schemas
  will suffer too.

Proposal: pg_extension, a new dedicated system schema for extensions
  It's easy to see SQL objects (\df) of extensions (think contribs) you
  installed, and as extension developpers are required to use it, you
  don't have to care about it any more.

  As you have only one namespace for everyone, the collisions are
  detected early.
Not good:
  As you have only one namespace for everyone, collisions prevent users
  from installing several extensions using the same SQL object name, so
  we'd need a way for extension authors to share a catalog of free
  names, like internally we do for systems OIDs in the bootstrap,
  IIUC. But in a distributed fashion.

  We would have to add ways for the user to see which extension which
  object belongs to, so you'd have extension | schema | object_name
  columns in all \dX things, e.g.

Proposal: allow user schema to behave the same as pg_catalog
  Tell the system your schema is implicit and be done with it, object
  searching won't need users to manage search_path explicitly.
Not good:
  Breaking existing application code by adding an implicit schema in an
  existing database is damn too easy. And how to choose if the implicit
  schemas are to be searched in before or after the search_path?

Proposal: Separate search_path into components: pre_search_path,
  search_path, post_search_path
  This allows to easily separate who changes what: typically DBAs will
  edit pre and post search_path components while application will care
  about search_path the same way as now. 
Not good:
  2 new GUCs (but no new semantics, and defaults to empty)

My vote is to go with the pre/post search_path components proposal as
it's the one allowing the more flexibility, and we tend to value this a
lot around here.



pgsql-hackers by date

Next:From: Itagaki TakahiroDate: 2009-05-25 09:39:39
Subject: BUG #4822: xmlattributes encodes '&' twice
Previous:From: Sebastien FLAESCHDate: 2009-05-25 07:32:00
Subject: Re: INTERVAL data type and libpq - what format?

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