Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> Thomas appears to want your schema search path to have some effect on
>> which casts you can see --- which I'm not at all sure I agree with,
>> but if that's the requirement then the above doesn't do it either.
> If I understand t
Tom Lane writes:
> Thomas appears to want your schema search path to have some effect on
> which casts you can see --- which I'm not at all sure I agree with,
> but if that's the requirement then the above doesn't do it either.
If I understand this right, this would be nearly analogous to determ
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Are the docs on our schema usage already available someplace ?
Yes, although there's not a pulled-together introduction (someone needs
to write a section for the tutorial, I think). Try
http://developer.postgresql.org/docs/postgres/sql-naming.html
and
On Thu, 2002-06-27 at 02:10, Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Perhaps it wouldn't be such a terrible idea after all to store the casting
> > paths separately, such as in a system table pg_cast (from, to, func,
> > implicit). This would implement the SQL99 spec fa
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Perhaps it wouldn't be such a terrible idea after all to store the casting
> paths separately, such as in a system table pg_cast (from, to, func,
> implicit). This would implement the SQL99 spec fairly exactly.
Well, maybe. One question is how that
Tom Lane writes:
> IIRC, a function is only considered to be a cast function if it matches
> by name *and schema* with the target type. So if you, for example,
> make a function public.int4(something), it'll never be considered a
> cast function for pg_catalog.int4. I had some doubts about that
Thomas Lockhart <[EMAIL PROTECTED]> writes:
>> IIRC, a function is only considered to be a cast function if it matches
>> by name *and schema* with the target type. So if you, for example,
>> make a function public.int4(something), it'll never be considered a
>> cast function for pg_catalog.int4.
> Another possibility is that you got burnt by some schema-related issue;
> cf the updated conversion docs at
> http://developer.postgresql.org/docs/postgres/typeconv-func.html
I'll bet that is it, though possible differences in CAST() behaviors are
not explained. I'll see if I can reproduce them
I said:
> Thomas Lockhart <[EMAIL PROTECTED]> writes:
>> I've got another issue with casting which I've run into while testing
>> this feature; afaict invoking an explicit CAST() in SQL does not
>> guarantee that the function of the expected name would be called, if
>> that function does not have
> I see no real reason why we should not require casting functions to
> follow the Postgres naming convention --- after all, what else would
> you name a casting function?
We do require casting functions to follow the Postgres naming
convention. istm to be a waste of time to have the CREATE CAST(
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> I've got another issue with casting which I've run into while testing
> this feature; afaict invoking an explicit CAST() in SQL does not
> guarantee that the function of the expected name would be called, if
> that function does not have the implicit f
Thomas Lockhart <[EMAIL PROTECTED]> writes:
>> So the closest you could
>> map it to would be
>> ALTER FUNCTION to(from) IMPLICIT CAST
> That would require that the function to be used as the cast have the
> same name as the underlying PostgreSQL conventions for casting
> functions. The implement
Thomas Lockhart writes:
> 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
> > 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 'sele
Rod Taylor writes:
> > I'm also looking at the SQL99 INFORMATION_SCHEMA views. Is anyone
> > already defining these? Is someone interested in picking this up?
> I've
> > got some definitions in a contrib-style directory but have not yet
> > mapped them to PostgreSQL.
>
> I have a few of the basic
I've gone ahead and committed patches for CREATE CAST/DROP CAST, as well
as for a few other SQL99 clauses in other statements. Details below...
- Thomas
Implement SQL99 CREATE CAST and DROP CAST statements.
Also implement alternative forms to expose the PostgreSQL CREATE
FUN
> > 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 f
> I'm also looking at the SQL99 INFORMATION_SCHEMA views. Is anyone
> already defining these? Is someone interested in picking this up?
I've
> got some definitions in a contrib-style directory but have not yet
> mapped them to PostgreSQL.
I have a few of the basics done, but nothing really signif
Thomas Lockhart writes:
> 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 a
19 matches
Mail list logo
