Re: [HACKERS] Missing array support
От
Tom Lane
Тема
Re: [HACKERS] Missing array support
Дата
Msg-id
17396.1057006221@sss.pgh.pa.us
Ответ на
Re: [HACKERS] Missing array support (Joe Conway)
Список
Дерево обсуждения
Re: [HACKERS] Missing array support Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Missing array support Joe Conway <mail@joeconway.com>
Re: [HACKERS] Missing array support Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Missing array support Joe Conway <mail@joeconway.com>
Re: [HACKERS] Missing array support Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Missing array support Joe Conway <mail@joeconway.com>
Re: [HACKERS] Missing array support Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Missing array support Joe Conway <mail@joeconway.com>
Joe Conway writes: > Are you referring to ANYELEMENT actually being an array at runtime? > That's the first time I've heard that concept. That was the behavior we agreed to some time ago, to avoid needing to entangle ANY into the polymorphism logic. See the comments for check_generic_type_consistency: * The argument consistency rules are: * * 1) All arguments declared ANYARRAY must have matching datatypes, * and must in fact be varlena arrays. * 2) All arguments declared ANYELEMENT must have matching datatypes. * 3) If there are arguments of both ANYELEMENT and ANYARRAY, make sure * the actual ANYELEMENT datatype is in fact the element type for * the actual ANYARRAY datatype. If only ANYELEMENT and not ANYARRAY appears in a function declaration, then it can stand for any type, because only rule 2 applies. (The difference from ANY is that multiple occurences of ANYELEMENT are all constrained to stand for the same type.) regards, tom lane
В списке pgsql-patches по дате отправления
От: Aizaz Ahmed
Дата: