Обсуждение: Array iterators
I really like array iterators, and am interested in simplifying them somewhat. Currently they required too many operator entries and functions to be truely useful in the base. Please fill in holes ;) Ok, first step. The ability to create an operator that will work on a vast number of data types without having to specify each one. This requires creation of functions which can accept type unknown, and more importantly an array of unknown. I don't think much (any?) modifcation will be required to arrayin() / arrayout() for this as unknown is basically a varchar. 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? We simply don't want to allow this special method for everything. Just a few special cases where comparing Datums is close enough. Array iterators and perhaps a generic '=' operator where one doesn't exist with a specific type tied to it that we can use instead. Step 3 is to have the iter operators use datumIsEqual(). The special cases that datumIsEqual doesn't work will get it's own set of array iterator functions. A list of these needs to be compiled, although it should be a short one. Doesn't seem like a great solution because I don't like coercing stuff back to unknown. Making a special generic type or using text in this case isn't much better as it's still arbirarily selecting when to coerce to it or not. Perhaps all thats needed is an interator function set per type group (ints, chars, bool, ...) It'll be a while before I do anything -- but perhaps for 7.4. -- Rod
"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
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 > >
Sounds great to me. Mostly why I made the remark that I wasn't happy with the solution due to using type unknown. any and _any it is. -- Rod ----- Original Message ----- From: "Nicolas Bazin" <nbazin@ingenico.com.au> To: "Rod Taylor" <rbt@zort.ca>; "Tom Lane" <tgl@sss.pgh.pa.us> Cc: "Hackers List" <pgsql-hackers@postgresql.org> Sent: Wednesday, May 15, 2002 3:10 AM Subject: Re: [HACKERS] Array iterators > 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 > > 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".