Re: proposal: auxiliary functions for record type
От | Florian Pflug |
---|---|
Тема | Re: proposal: auxiliary functions for record type |
Дата | |
Msg-id | 4354975A-E627-458B-8B0D-1D2E6270CD68@phlo.org обсуждение исходный текст |
Ответ на | Re: proposal: auxiliary functions for record type (Pavel Stehule <pavel.stehule@gmail.com>) |
Ответы |
Re: proposal: auxiliary functions for record type
Re: proposal: auxiliary functions for record type |
Список | pgsql-hackers |
On Dec11, 2010, at 17:55 , Pavel Stehule wrote: > It same trick, that I use in record_set_fields. Oh, I see. Sorry, must haven missed that when I read your blog entry. > But I don't want to > use it for reading of value. I don't like it. You don't need to know a > value, you have to know a type - NULL::type. it is just not nice :). Well, no, it's not the most elegant API on earth, that's for sure. But I my opinion, it isn't so bad that it rectifies castingeverything to text. > I > though about it too, and maybe is a time for new polymorphic type > "anytype" - and then you don't need to write a litte bit strange > NULL::type > > it can be "fieldvalue(myrec, type1, false)" Hm, I don't think the ability to write just "type1" instead of "NULL::type1" is worth the necessary effort. If anything, I'd allow function to use anyelement as their return value *without* having any polymorphic arguments. You'dneed to surround calls to such function with a CAST() expression, unless something else determines the type. In pl/pgsql,for example, one could allow the CAST() to be skipped for assignment to variables. Then, you could writev_value:= fieldvalue(myrec, 'f1', true) That'd at least free you from having to specify the type in some cases. But still, even this seems to be a lot of effortfor quite little gain... best regards, Florian Pflug
В списке pgsql-hackers по дате отправления: