Re: BUG #18190: PL/pgSQL does not document comparison operations on RECORD (or ROW) types
От | Tom Lane |
---|---|
Тема | Re: BUG #18190: PL/pgSQL does not document comparison operations on RECORD (or ROW) types |
Дата | |
Msg-id | 1740510.1699804414@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #18190: PL/pgSQL does not document comparison operations on RECORD (or ROW) types ("Karl O. Pinc" <kop@karlpinc.com>) |
Список | pgsql-bugs |
"Karl O. Pinc" <kop@karlpinc.com> writes: > Perhaps I'm too used to reading the PL/pgSQL chapter, which > makes it sound like RECORD variables are strictly a PL/pgSQL > construct. (And maybe they are.) It's unclear why this would matter, > and how such a thought would throw off my searching. But something > did. Variables in general are a PL/pgSQL construct, but RECORD can be used in other contexts; for example as the argument or return type of a function, whether it's in PL/pgSQL or not. (Some PLs may reject that, but that's an implementation shortcoming of the PL.) Also, the result of any ROW() constructor is of type RECORD unless it's cast to some named composite type. > (FWIW, The sentence "Note that RECORD is not a true data type, > only a placeholder." is pretty mysterious. I don't see anything > that informs me about what a RECORD variable is, composite, > ROW type, or whatever.) I think you are on to something here. I'm not very sure what we should write instead of what's there, but I think that that sentence predates our invention of polymorphic types. It would likely be better to frame RECORD as a polymorphic type that can range over (only) composite types, and to provide cross-references to the main docs' sections about composites (and maybe polymorphics). Too caffeine-deprived to propose any specific wording, but I think this area could use some work. regards, tom lane
В списке pgsql-bugs по дате отправления: