Re: VARIANT / ANYTYPE datatype
От | Merlin Moncure |
---|---|
Тема | Re: VARIANT / ANYTYPE datatype |
Дата | |
Msg-id | BANLkTinn_YQKSFMxYw=OyedmcSB-H97REg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: VARIANT / ANYTYPE datatype (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Wed, May 4, 2011 at 12:36 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Alvaro Herrera <alvherre@alvh.no-ip.org> writes: >> A customer came to us with this request: a way to store "any" data in a >> column. We've gone back and forth trying to determine reasonable >> implementation restrictions, safety and useful semantics for them. > > Yes, it seems rather messy. > >> The main idea is to be able to store column values in an audit table >> like this: >> old_value variant >> new_value variant >> Currently, they use text for old_value and new_value, but this is, of >> course, not very satisfactory. > > Just out of curiosity, what actual functionality gain would ensue over > just using text? It seems like doing anything useful with the audit > table contents would still require casting the column to text, or the > moral equivalent of that. The problem with text is that for composite/table types you lose the ability to cast back when the structure changes. Most of the auditing implementations I've done cast new/old to text and drop it directly into a single column on the audit record. It works ok, but you have to messily update the text later when the table changes. For non-variant composites you can add columns down the line and it works ok in dependent records without too much fuss. I think though that getting this to work such that type dependency is via row/column instead of just column is going to be tough. Outside of composites, I don't see much advantages vs the text route, performance maybe? merlin
В списке pgsql-hackers по дате отправления: