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

Re: contrib function naming, and upgrade issues

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: contrib function naming, and upgrade issues
Date: 2009-03-24 08:24:49
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers

attention, MODULE is ANSI SQL keyword, and modules are class from ANSI SQL.

<SQL-server module definition> ::=
  CREATE MODULE <SQL-server module name>
      [ <SQL-server module character set specification> ]
      [ <SQL-server module schema clause> ] [ <SQL-server module path
specification> ]
      [ <temporary table declaration>... ]
      <SQL-server module contents>...
<SQL-server module character set specification> ::=
  NAMES ARE <character set specification>
<SQL-server module schema clause> ::=
  SCHEMA <default schema name>
<default schema name> ::=
  <schema name>
<SQL-server module path specification> ::=
  <path specification>
<SQL-server module contents> ::=
  <SQL-invoked routine> <semicolon>

Pavel Stehule

2009/3/23 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> ...  I suspect that it's going to boil down to running a
>> SQL script, which will need to somehow get that module installed.  To
>> make that work, I think we need "CREATE MODULE foo" and then "CREATE
>> <TABLE|VIEW|FUNCTION|...> ... MODULE foo".  So the SQL script will
>> create the module and then create all of the objects and make them
>> depend on the module using the optional "MODULE foo" clause.
> I doubt that we want to decorate every CREATE statement we've got with
> an optional MODULE clause; to name just one objection, it'd probably
> be impossible to do so without making MODULE a fully reserved word.
> What was discussed in the last go-round was some sort of state-dependent
> assignment of a module context.  You could imagine either
>        BEGIN MODULE modname;
>        CREATE this;
>        CREATE that;
>        CREATE the_other;
>        END MODULE;
> or something along the lines of
>        SET current_module = modname;
>        CREATE this;
>        CREATE that;
>        CREATE the_other;
>        SET current_module = null;
> which is really more or less the same thing except that it makes the
> state concrete in the form of an examinable variable.  In either case
> you'd need to define how the state would interact with transactions
> and errors.
>                        regards, tom lane
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:

In response to

pgsql-hackers by date

Next:From: Zdenek KotalaDate: 2009-03-24 11:23:56
Subject: Re: cs_CZ vs regression tests, part N+1
Previous:From: Peter EisentrautDate: 2009-03-24 07:43:44
Subject: Re: cs_CZ vs regression tests, part N+1

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