Re: SQL99, CREATE CAST, and initdb

> > I've got patches for the CREATE CAST/DROP CAST feature (just a
> > rearrangement of our existing function declaration syntax). The SQL99
> > form assumes that an existing function will be used for the cast
> > definition, so I've extended the syntax to allow that and to have an
> > alternate form which has more of our CREATE FUNCTION functionality.
> Could you provide more precise details? I've thought of this before, when
> the new "may be a cast function" feature was added, and this feature
> didn't match very well.

It doesn't match perfectly in that one field is ignored as being
(afaict) redundant for us. The basic definition from SQL99 is

CREATE CAST(from AS to) WITH FUNCTION func(args) [AS ASSIGNMENT]

I can map this to something equivalent to

CREATE FUNCTION to(from) RETURNS to AS 'select func($1)' LANGUAGE 'sql';

with another clause or two to get the implicit coersion enabled, and
ignoring the "args" field(s).

This supposes that a coersion function of some other name already
exists, and if I define one it seems to work nicely. I defined two
alternate forms, one resembling the SQL99 clauses and one resembling the
existing PostgreSQL CREATE FUNCTION clauses, as follows:

CREATE CAST(from AS to) WITH FUNCTION func(args) AS 'path' WITH ...

and

CREATE CAST(from AS to) AS 'path' WITH ...

and both of these latter forms allow one to eliminate a corresponding
CREATE FUNCTION.

> > I'm also looking at the SQL99 INFORMATION_SCHEMA views. Is anyone
> > already defining these?
> Yes. I'm done through section 20.18 (COLUMNS view).

Great. I'll stop looking at it then.

> > The initdb folks may want to start thinking about the best way to
> > support a larger number of views; currently they are embedded directly
> > into the initdb script but that would get unwieldy with more of them
> > (and some of them are *really* fat definitions!).
> I think they can be loaded from an external file.

Sounds good.

- Thomas