On Sep 29, 2008, at 6:16 AM, [EMAIL PROTECTED] wrote:
The hstore module, as I said,
looks really cool, I've contemplated something like it. I have a
module
provides a set of accessors for an XML text column that works
similarly,
but it parses the XML on each access and the application has to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sun, Sep 28, 2008 at 09:24:48PM -0700, David E. Wheeler wrote:
On Sep 28, 2008, at 17:46, Tom Lane wrote:
BTW, I think it is (or should be) possible to create an index on
hstore-'mycol', so at least one of the reasons why you should *need*
to
What you're talking about is a document based database like
StrokeDB, CouchDB. With hstore you don't need to parse content of
'aggregate' column, it provides necessary methods. Also, we tried
to speedup selects using indexes. Probably, we need to refresh our
interest to hstore, do you have
On Sep 28, 2008, at 23:46, [EMAIL PROTECTED] wrote:
I'm not sure what that means. Can you create normal btree or hash
indexes
on hstore columns? And is the index useful for both `@` and `?`?
That means that those operations are supported by a GiST (or GIN)
index,
that is:
find the
I was in a discussion with someone about the difference between ad-hoc
storage systems and SQL. Yes, I know, I was rolling my eyes as well. One
thing did strike me though was the idea that a table could contain a
variable number of columns.
Something like this:
create adhoc table foo ();
insert
[EMAIL PROTECTED] writes:
Something like this:
create adhoc table foo ();
insert into foo (name, rank, serial) values ('joe', 'sargent', '42');
In an ad-hoc table type, when an insert is made, and a column is not
found, then a new varchar column is added.
I know the idea has a lot of
[EMAIL PROTECTED] writes:
Something like this:
create adhoc table foo ();
insert into foo (name, rank, serial) values ('joe', 'sargent', '42');
In an ad-hoc table type, when an insert is made, and a column is not
found, then a new varchar column is added.
I know the idea has a lot of
[EMAIL PROTECTED] writes:
Being able to insert arbitrary named values, and extracting them
similarly, IMHO works better and more naturally than some external
aggregate system built on a column. I know it is a little outside the
box thinking, what do you think?
I'm failing to see the point.
Not that I'm agreeing with the direction but just as a thinking experiment:
Tom Lane wrote:
[EMAIL PROTECTED] writes:
Being able to insert arbitrary named values, and extracting them
similarly, IMHO works better and more naturally than some external
aggregate system built on a column. I
[EMAIL PROTECTED] writes:
Being able to insert arbitrary named values, and extracting them
similarly, IMHO works better and more naturally than some external
aggregate system built on a column. I know it is a little outside the
box thinking, what do you think?
I'm failing to see the point.
On Sep 28, 2008, at 17:46, Tom Lane wrote:
BTW, I think it is (or should be) possible to create an index on
hstore-'mycol', so at least one of the reasons why you should *need*
to switch to a real database column seems bogus.
The docs say:
titleIndexes/title
para
typehstore/ has
What you're talking about is a document based database like
StrokeDB, CouchDB. With hstore you don't need to parse content of
'aggregate' column, it provides necessary methods. Also, we tried
to speedup selects using indexes. Probably, we need to refresh our
interest to hstore, do you have any
12 matches
Mail list logo
