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

Re: contrib function naming, and upgrade issues

From: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, Dave Page <dpage(at)pgadmin(dot)org>, 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 20:34:11
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
>>>>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

 Tom> I think the way most people are envisioning this is that a
 Tom> module is a set of SQL objects (functions, types, tables,
 Tom> whatever).  Whether any of those are C functions in one or more
 Tom> underlying .so files is not really particularly relevant to the
 Tom> module mechanism.

 Tom> It should be possible to have a module that doesn't contain any
 Tom> C code,


 Tom> so the concept of a defining function does not look good to me.
 Tom> A defining SQL script is the way to go.

But I disagree with this, for the simple reason that we don't have
anything like enough flexibility in the form of conditional DDL or
error handling, when working in pure SQL without any procedural help.
This is especially true when you start to look at how to handle
conflicts, upgrades and versioning.


In response to


pgsql-hackers by date

Next:From: Josh BerkusDate: 2009-03-23 22:34:12
Subject: Re: hstore improvements?
Previous:From: Joshua D. DrakeDate: 2009-03-23 20:27:56
Subject: Re: Unsupported effective_io_concurrency platforms

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