Thread: 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