On Sunday 10 April 2005 19:10, Jim C. Nasby wrote:
> In working on the newsysviews project we've discovered that there's no
> definitive way to determine if a cast is a system cast (system as in
> part of postgresql/created by createdb) or not. What pg_dump does (and
> what we're doing now for lack of a better solution) is any cast that
> doesn't involve a user-created type, or a user-created conversion
> function is considered a system cast. This means if a user creates a
> cast between two different system types using a system function (to use
> a bad example, say text->int), that cast won't show up in pg_user_casts,
> and more important, it won't be backed up by pg_dump.
>
> This seems sub-optimal. :)
>
> Is there a reasonable way to fix this? For most objects, you can
> determine if it's a system object or not based on the schema it lives
> in. So, one possibility is to put casts into schemas. This would have
> the added effect of allowing you to 'hide' a cast by removing it's
> schema from search_path.
>
> Another possibility would be to add an is_system column to pg_cast.
> Casts created by the system as part of database creation (or at least
> the initial creation of the template databases) would have this field
> set to true, whereas user created casts would have it set to false.
> Instead of having two seperate methods to create casts, you could do a
> bulk update of pg_cast as part of database creation.
>
> Thoughts?
One potential ugly way to do it would be to use the magical "last system oid"
as a differentiator between those created by pg and those created by the
user. It would be different for every version so that might be a problem.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
