Re: Suggestions please: names for function cachabilityattributes

Tom Lane writes:

Peter Eisentraut <peter_e@gmx.net> writes:

Tom Lane writes:

case 1: "immutable"
case 2: "mutable", or perhaps "stable"
case 3: "volatile"

Since they've changed anyway, how about dropping the silly "is" in front
of the names?

"volatile" would conflict with a C keyword. Possibly we could get away
with this at the SQL level, but I was worried...

In general, I was thinking about migrating the CREATE FUNCTION syntax more
into consistency with other commmands and with the SQL standard.
Basically I'd like to write

CREATE FUNCTION name (args, ...) RETURNS type
AS '...'
LANGUAGE foo
STATIC
IMPLICIT CAST

(where everything after RETURNS can be in random order).

OK, so the key words are not the same as SQL, but it looks a lot
friendlier this way. We're already migrating CREATE DATABASE, I think,
and the names of the options have changed, too, so this might be a good
time.

--
Peter Eisentraut peter_e@gmx.net

Peter Eisentraut <peter_e@gmx.net> writes:

Basically I'd like to write

CREATE FUNCTION name (args, ...) RETURNS type
AS '...'
LANGUAGE foo
STATIC
IMPLICIT CAST

(where everything after RETURNS can be in random order).

No strong objection here; but you'll still have to accept the old syntax
for backwards compatibility with existing dump scripts. I also worry
that this will end up forcing us to reserve a lot more keywords. Not so
much for CREATE FUNCTION, but in CREATE OPERATOR, CREATE DOMAIN and
friends I do not think you'll be able to do this without making the
keywords reserved (else how do you tell 'em from parts of typenames
and expressions?).

Given that it's not gonna be SQL-spec anyway, I'm not entirely sure
I see the point of changing.

regards, tom lane