Re: pgsql: Implement a preliminary 'template' facility for procedural

Log Message:
-----------
Implement a preliminary 'template' facility for procedural languages,
as per my recent proposal. For now the template data is hard-wired in
proclang.c --- this should be replaced later by a new shared system
catalog, but we don't want to force initdb during 8.1 beta. This change
lets us cleanly load existing dump files even if they contain outright
wrong information about a PL's support functions, such as a wrong path
to the shared library or a missing validator function. Also, we can
revert the recent kluges to make pg_dump dump PL support functions that
are stored in pg_catalog.
While at it, I removed the code in pg_regress that replaced $libdir
with a hardcoded path for temporary installations. This is no longer
needed given our support for relocatable installations.

Modified Files:
--------------
pgsql/doc/src/sgml/ref:
create_language.sgml (r1.39 -> r1.40)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/ref/create_language.sgml.diff?r1=1.39&r2=1.40)
createlang.sgml (r1.35 -> r1.36)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/ref/createlang.sgml.diff?r1=1.35&r2=1.36)
pgsql/doc/src/sgml:
xplang.sgml (r1.28 -> r1.29)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/xplang.sgml.diff?r1=1.28&r2=1.29)
pgsql/src/backend/commands:
proclang.c (r1.60 -> r1.61)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/proclang.c.diff?r1=1.60&r2=1.61)
pgsql/src/backend/parser:
gram.y (r2.509 -> r2.510)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/parser/gram.y.diff?r1=2.509&r2=2.510)
pgsql/src/bin/pg_dump:
pg_dump.c (r1.419 -> r1.420)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/bin/pg_dump/pg_dump.c.diff?r1=1.419&r2=1.420)
pg_dump.h (r1.120 -> r1.121)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/bin/pg_dump/pg_dump.h.diff?r1=1.120&r2=1.121)
pgsql/src/bin/scripts:
createlang.c (r1.19 -> r1.20)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/bin/scripts/createlang.c.diff?r1=1.19&r2=1.20)
pgsql/src/test/regress:
pg_regress.sh (r1.59 -> r1.60)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/pg_regress.sh.diff?r1=1.59&r2=1.60)

On Mon, Sep 05, 2005 at 08:50:49PM -0300, Tom Lane wrote:
> Log Message:
> -----------
> Implement a preliminary 'template' facility for procedural languages,
> as per my recent proposal.

Yay!

> For now the template data is hard-wired in proclang.c --- this
> should be replaced later by a new shared system catalog, but we
> don't want to force initdb during 8.1 beta.

Wouldn't beta be the time to do it? I know we define initdb-forcing
changes to mean a major version bump, but I also thought that beta was
a time to find the places where such changes make sense. Has there
been a guarantee that beta means "no initdb" in previous releases?

Just my $.02.

Cheers,
D
--
David Fetter david(at)fetter(dot)org http://fetter.org/
phone: +1 510 893 6100 mobile: +1 415 235 3778

Remember to vote!

On Sep 6, 2005, at 11:34 AM, David Fetter wrote:
> On Mon, Sep 05, 2005 at 08:50:49PM -0300, Tom Lane wrote:
>
>> For now the template data is hard-wired in proclang.c --- this
>> should be replaced later by a new shared system catalog, but we
>> don't want to force initdb during 8.1 beta.
>>
>
> Wouldn't beta be the time to do it? I know we define initdb-forcing
> changes to mean a major version bump, but I also thought that beta was
> a time to find the places where such changes make sense. Has there
> been a guarantee that beta means "no initdb" in previous releases?
>
> Just my $.02.

I've been thinking the same thing. Beta is a time for shaking things
out and getting them right, isn't it?

My ¥2 (at current exchange rates, approximately USD 0.0183)

Michael Glaesemann
grzm myrealbox com

David Fetter <david(at)fetter(dot)org> writes:
>> For now the template data is hard-wired in proclang.c --- this
>> should be replaced later by a new shared system catalog, but we
>> don't want to force initdb during 8.1 beta.

> Wouldn't beta be the time to do it? I know we define initdb-forcing
> changes to mean a major version bump, but I also thought that beta was
> a time to find the places where such changes make sense. Has there
> been a guarantee that beta means "no initdb" in previous releases?

No, but we avoid initdb after beta1 when we can. Our long-suffering
beta testers don't need to be whacked around unnecessarily.

If something comes along that forces an initdb (for instance, we find
something wrong with ROLEs that can't be fixed without a catalog change)
then I'll think hard about pushing in the additional changes to create a
pltemplate system catalog. But it seemed easier to sell the idea as a
non-initdb-forcing change ...

regards, tom lane