Re: Coping with 'C' vs 'newC' function language names

From: Philip Warner <pjw(at)rhyme(dot)com(dot)au>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Coping with 'C' vs 'newC' function language names
Date: 2000-11-12 03:37:36
Message-ID: 3.0.5.32.20001112143736.02bc9920@mail.rhyme.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At 20:30 11/11/00 -0500, Tom Lane wrote:
>
>The current fmgr implementation requires PL handlers to be newC or
>newInternal. That could be relaxed, but I don't see any reason to do
>so, since an old-style handler would be incapable of handling null
>arguments/results or supporting triggers.

OK, then given this, the CREATE LANGUAGE statement really should output a
warning and/or force a change in the language.

>> It does avoid "language 'evenNewerC'" in the furture.
>
>How so? It appears to me it would just move the 'evenNewerFoo'
>dirtiness to a different keyword, which would still be essential
>for the user to write. Net result: no gain, just more writing.

Well the gain is that by version 8.3 we won't be requiring all new
functions to use 'veryVeryExtraSpecialC' as their language name. The
clutter has no negative effect on updated and new functions. Equally well,
if we use pg_fmgr_info or similar the problem will go away.

>> Quite right. The (unspecified) plan was to allow an environmental setting
>> that set the default attr for "language 'C'" functions. Then restoring a
>> dump file would be a matter of setting this variable to use the old
>> interface at the start of the script.
>
>Interesting idea, but it'll fall down as soon as there's more than one
>possible value. You don't think that people are going to update all
>their functions to a new interface style at the same time, do you?

No, but when restoring from pg_dump, they will (initially, I assume) be
working with old function definitions. Newer versions of pg_dump would dump
the appropriate attribute.

>> Might even be able to implement a 'CREATE MODULE' which loads an
>> object, enquires about functions in the module, and creates function
>> entries based on information returned from pg_fmgr_info...
>
>That could work ... something to think about for the future, anyway.

Yep.

----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.B.N. 75 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 0500 83 82 82 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alfred Perlstein 2000-11-12 07:00:50 Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)
Previous Message Philip Warner 2000-11-12 02:43:56 Re: Coping with 'C' vs 'newC' function language names