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

Re: contrib function naming, and upgrade issues

From: Greg Stark <greg(dot)stark(at)enterprisedb(dot)com>
To: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, 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-23 03:26:03
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Why do you need any explicit syntax? If the database is loading an SQL  
file as a result of a LOAD MODULE command wouldn't it know to set  
whatever internal state it needs to remember that?


On 22 Mar 2009, at 23:11, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>  

>>>>>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Tom> I doubt that we want to decorate every CREATE statement we've
> Tom> got with an optional MODULE clause; to name just one objection,
> Tom> it'd probably be impossible to do so without making MODULE a
> Tom> fully reserved word.
> Tom> What was discussed in the last go-round was some sort of
> Tom> state-dependent assignment of a module context.  You could
> Tom> imagine either
> [snip]
> Tom> or something along the lines of
> Tom>    SET current_module = modname;
> Tom>    CREATE this;
> Tom>    CREATE that;
> Tom>    CREATE the_other;
> Tom>    SET current_module = null;
> Tom> which is really more or less the same thing except that it makes
> Tom> the state concrete in the form of an examinable variable.  In
> Tom> either case you'd need to define how the state would interact
> Tom> with transactions and errors.
> I like the SET version better. As for transactions and errors, I think
> that installing a module should be done inside a transaction anyway;
> and the usual GUC mechanisms should handle it if it was done using
> SET LOCAL, no?
> -- 
> Andrew.
> -- 
> 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: higeponDate: 2009-03-23 08:14:27
Subject: pg_dump Add dumping of comments on index columns
Previous:From: Andrew GierthDate: 2009-03-23 03:11:08
Subject: Re: contrib function naming, and upgrade issues

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