Re: Array iterators - Mailing list pgsql-hackers

Just a small remark, type name "any" would be more meaningfull than
"unknown". Also it's widely used (CORBA for example) and may enter in the
STL someday.

----- Original Message -----
From: "Tom Lane" <tgl@sss.pgh.pa.us>
To: "Rod Taylor" <rbt@zort.ca>
Cc: "Hackers List" <pgsql-hackers@postgresql.org>
Sent: Wednesday, May 15, 2002 2:48 PM
Subject: Re: [HACKERS] Array iterators


> "Rod Taylor" <rbt@zort.ca> writes:
> > Step 2 is to teach oper_select_candidate() about functions which
> > accept unknown and _unknown that can be used as a last resort.  We
> > will allow coercions to type unknown and _unknown from any type to
> > accomplish this but only in this specific case.  Why unknown and not
> > text?
>
> Rather than unknown, how about some new special pseudo-type?
>
> We've already shot ourselves in the feet enough times by overloading
> type OID 0 to mean so many slightly-different things.  I have ranted
> on this topic before, see the archives; but even past midnight I can
> name several distinct meanings of "type 0" without stopping for breath:
> plain old invalid placeholder, as in pg_proc.proargtypes entries beyond
> the pronargs'th one; C string for I/O functions; takes/returns an
> internal type, as in the various cost estimation functions for the
> optimizer and the various index access method functions (note there are
> several *different* internal types involved there), not to mention
> trigger functions which really really ought to have a distinguishable
> signature; "returns void"; "takes any type at all" (COUNT(*)); "takes
> any array type" (array_dims); ... okay, I'm out of breath.
>
> Meanwhile in the type resolver's domain we have "unknown" literals,
> and we've speculated many times about inventing "unknown numeric"
> literals to clean up the problems with assignment of types to numeric
> constants.  Let's *not* make the mistake of overloading "unknown" to
> have some array-specific meaning.
>
> I believe that the best ultimate resolution of these problems will
> involve creating a spectrum of "pseudo-types" with different, sharply
> defined meanings.  Breaking up "opaque/type 0" is going to cause a
> lot of backward-compatibility pain, so I have not been in a big hurry
> to do it --- but let's get it right the first time when dealing with
> shades of "unknown".
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html
>
>