Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I feel the best idea for a non-initdb-forcing solution is to hardwire
>> the template knowledge into CREATE LANGUAGE for 8.1 (with of course the
>> intention of doing my full original proposal for 8.2). With that in
>> place, the only
Tom Lane wrote:
I feel the best idea for a non-initdb-forcing solution is to hardwire
the template knowledge into CREATE LANGUAGE for 8.1 (with of course the
intention of doing my full original proposal for 8.2). With that in
place, the only messiness from loading old dumps is that you would
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I agree with Tom that it should not be done at this stage of beta. But
> maybe we should look again at the much lower impact suggestion I made
> when we moved the handlers and validators to pg_catalog, which was to
> have pg_dump also do that move rat
elein wrote:
On Wed, Aug 31, 2005 at 05:56:52PM -0400, Tom Lane wrote:
[ interesting scheme for language handlers ]
It's a shame that we didn't think about this before feature freeze,
as the recent changes to create PL support functions in pg_catalog
have made both pg_dump and createlang
[EMAIL PROTECTED] (elein) writes:
> On Wed, Aug 31, 2005 at 05:56:52PM -0400, Tom Lane wrote:
>> The basic idea is to create a shared catalog that contains "procedural
>> language templates". This catalog would essentially replace the
>> knowledge that's now hardwired in the createlang program.
>>
On Wed, Aug 31, 2005 at 05:56:52PM -0400, Tom Lane wrote:
> I wrote:
> > We've had repeated problems with PL languages stemming from the fact
> > that pg_dump dumps them at a pretty low semantic level. Aside from this
> > problem with adding a validator, we used to have issues with hardwired
> > p
