Обсуждение: createlang and Schemas
createlang seems not to take a schema argument. Should it? I am trying to get rid of public, but if I use createlang first,it depends on public, and if I try to use it later, I can't specify a schema. I can just create language for now, but createlang is handy... I love 7.3. Ian
"Ian Harding" <ianh@tpchd.org> writes:
> createlang seems not to take a schema argument. Should it?
Hm. The language itself does not have any associated schema --- but the
underlying call handler function does. Perhaps there should be a way to
tell createlang which schema to put the function in. Right now it will
be effectively determined by the default search path, so you could do
PGOPTIONS='--search_path=myschema' createlang plpgsql mydb
but this seems inelegant.
regards, tom lane
Ian Harding writes: > createlang seems not to take a schema argument. Should it? Schema of what? Languages do not live in schemas. -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut wrote: > Ian Harding writes: > >> createlang seems not to take a schema argument. Should it? > > Schema of what? Languages do not live in schemas. Languages not, but language call handler functions do. Since languages are global to the database, I think the location for the call handler functions should be the pg_catalog schema. Currently, that creates a problem with pg_dump: http://archives.postgresql.org/pgsql-general/2002-12/msg01098.php http://archives.postgresql.org/pgsql-general/2003-01/msg00006.php Jochem
Hi all, Any caveat upgrading from 7.2.1 to 7.3.x on RH 7.3? Like for example: pg_access, perl's DBI::pg, function and/or keyword no longer supported, different behaviours, etc I know about COPY not converting '' to 0, but what about the rest? I am craving for SCHEMA... JLL
Is this a TODO? Not sure. --------------------------------------------------------------------------- Tom Lane wrote: > "Ian Harding" <ianh@tpchd.org> writes: > > createlang seems not to take a schema argument. Should it? > > Hm. The language itself does not have any associated schema --- but the > underlying call handler function does. Perhaps there should be a way to > tell createlang which schema to put the function in. Right now it will > be effectively determined by the default search path, so you could do > > PGOPTIONS='--search_path=myschema' createlang plpgsql mydb > > but this seems inelegant. > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
See HISTORY file in 7.3 release or release notes. --------------------------------------------------------------------------- Jean-Luc Lachance wrote: > Hi all, > > > Any caveat upgrading from 7.2.1 to 7.3.x on RH 7.3? > > Like for example: > > pg_access, perl's DBI::pg, function and/or keyword no longer supported, > different behaviours, etc > > I know about COPY not converting '' to 0, but what about the rest? > > I am craving for SCHEMA... > > JLL > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073