Обсуждение: Spec on pg_cast table/CREATE CAST command

Command syntax is
 CREATE CAST (source AS target) WITH FUNCTION name(arg) [AS ASSIGNMENT]

in compliance with SQL99 (AS ASSIGNMENT means implicitly invokable).

Declaration of binary compatible casts:
 CREATE CAST (source AS target) WITHOUT FUNCTION [AS ASSIGNMENT]

Does not have to be implicit (although it must be for use in function
argument resultion, etc.).  You must declare both directions explicitly.

Cast functions must be immutable.  This is following SQL99 as well.

Compatibility:

The old way to create casts has already been broken in 1.5 ways: the
introduction of the implicit flag and the introduction of schemas.  To
maintain full compatibility we'd have to revert to making the implicit
flag the default, which would undermine the compliance of the new CREATE
CAST command from the start.

Hence I suggest that we migrate through pg_dump: User-defined functions
that would have been casts up to 7.2 will emit an appropriate CREATE CAST
command.  This in combination with a release note will also give the users
a better chance to inspect the dump and adjust the cast specifications for
implicitness as they wish.

Comments?

-- 
Peter Eisentraut   peter_e@gmx.net

Peter Eisentraut <peter_e@gmx.net> writes:
> Command syntax is
>   CREATE CAST (source AS target) WITH FUNCTION name(arg) [AS ASSIGNMENT]
> in compliance with SQL99 (AS ASSIGNMENT means implicitly invokable).
> Declaration of binary compatible casts:
>   CREATE CAST (source AS target) WITHOUT FUNCTION [AS ASSIGNMENT]

So the idea is to remove proimplicit again?  We could still do that
before 7.3, since no user depends on it yet.  Are you intending a new
system catalog to hold casts?
        regards, tom lane

Tom Lane writes:

> So the idea is to remove proimplicit again?  We could still do that
> before 7.3, since no user depends on it yet.  Are you intending a new
> system catalog to hold casts?

Yeah, it seems I forgot to mention that.

Btw., it occurred to me that this could also be the direction to
generalize the "preferred type" games for resolving union and case
constructs.  Each declared cast could carry some additional properties,
such as "possibly truncating", "possible precision loss", or simply
"preferred", which could help the system to make smarter choices (such as
not doing int4+int8=int4).

-- 
Peter Eisentraut   peter_e@gmx.net

Could anyone familiar with the pg version of GiST tell me if the
framework allows entries in the tree as non-uniform sizes (in other
words, variable-length keys)? I want to write an extension for a
TV-tree, but this is an essential component.
Thanks;
Eric Redmond

Yes, our GiST supports variable-length keys.
Take a look on http://www.sai.msu.su/~megera/postgres/gist/

Oleg
On Wed, 17 Jul 2002, Eric Redmond wrote:

> Could anyone familiar with the pg version of GiST tell me if the
> framework allows entries in the tree as non-uniform sizes (in other
> words, variable-length keys)? I want to write an extension for a
> TV-tree, but this is an essential component.
> Thanks;
> Eric Redmond
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
>
Regards,    Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83