Skip site navigation (1) Skip section navigation (2)

Re: [GENEAL] dynamically changing table

From: Alban Hertroys <dalroi(at)solfertje(dot)student(dot)utwente(dot)nl>
To: Harald Fuchs <hari(dot)fuchs(at)gmail(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: [GENEAL] dynamically changing table
Date: 2009-03-31 17:39:21
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-general
On Mar 31, 2009, at 6:41 PM, Harald Fuchs wrote:

> In article <437FAA9F-DF2D-429E-9856-EB2026B55940(at)solfertje(dot)student(dot)utwente(dot)nl 
> >,
> Alban Hertroys <dalroi(at)solfertje(dot)student(dot)utwente(dot)nl> writes:
>> You could add the columns you're sure that you need and put the rest
>> in an XML field.
> <mantra>
> If you have a problem and want to solve it using XML, you have two  
> problems.
> </mantra>

A mantra is never good argumentation, whether for or against.

I don't like mantras, they're like dogmas, they prevent people from  
thinking. I consider them dangerous ;)

> Why serializing the rest of the data in an XML field?  contrib/hstore
> seems to accomplish the same, without the XML overhead.

Although I'm no fan of XML, it does have it's benefits. In this case,  
it's standardised (which means there are libraries for about every  
language to deal with XML data), it can store and constrain type  
information (although a bit limited IMO) about the data and there are  
many tools for manipulating data contained in XML and those can  
usually also be used at the application side of things.

contrib/hstore doesn't do these things for you, so it adds problems of  
its own. The OP may run into problems with database layers in his  
programming language of choice that can't deal with the specifics of  
querying a hstore field for example. If type information in the data  
is of importance, he'll have to explicitly cast the data (based on the  
key field). If certain fields are constrained to certain value ranges,  
he'll have to check those in his application.

It all depends on the requirements of the OP and how far he wants to  
go with this, if hstore solves his problem, by all means, go with it.  
In either case, using an XML field is a valid solution. Nobody said  
it's a perfect one.

Alban Hertroys

If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.


In response to

pgsql-general by date

Next:From: justinDate: 2009-03-31 17:44:19
Subject: Re: string_to_array with empty input
Previous:From: Greg StarkDate: 2009-03-31 17:06:03
Subject: Re: string_to_array with empty input

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group