On 3/19/09 2:40 PM, Dimitri Fontaine wrote:
Hi,
Le 19 mars 09 à 21:23, Josh Berkus a écrit :
One request I've had is to construct a record (of some supplied
composite type) from an hstore.
I'm not sure if this is even possible; I'm certainly not seeing a way
to implement it. Am I missing
Josh == Josh Berkus j...@agliodbs.com writes:
Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
As an hstore user, I'd be fine with simply limiting it to 64K (or,
heck, 8K) and throwing an error. I'd also be fine with limiting
keys to 255 bytes, although we'd have to warn people.
Andrew,
One request I've had is to construct a record (of some supplied
composite type) from an hstore.
I'm not sure if this is even possible; I'm certainly not seeing a way
to implement it. Am I missing something?
Well, presumably you'd try to match hstore tags against the columns of
the
On 3/19/09 1:23 PM, Josh Berkus wrote:
Andrew,
One request I've had is to construct a record (of some supplied
composite type) from an hstore.
I'm not sure if this is even possible; I'm certainly not seeing a way
to implement it. Am I missing something?
Well, presumably you'd try to match
Hi,
Le 19 mars 09 à 21:23, Josh Berkus a écrit :
One request I've had is to construct a record (of some supplied
composite type) from an hstore.
I'm not sure if this is even possible; I'm certainly not seeing a way
to implement it. Am I missing something?
Well, presumably you'd try to match
Andrew == Andrew Gierth and...@tao11.riddles.org.uk writes:
Andrew I have a patch almost done that adds some obvious but
Andrew currently missing functionality to hstore, specifically the
Andrew ability to construct an hstore from a record, and the ability
Andrew to construct one from a pair
Ron == Ron Mayer rm...@cheapcomplexdevices.com writes:
Ron Currently hstore gives me an indexed operator to query if a
Ron hstore contains a single key. It'd be nice if there were as way
Ron to extend this so that I could ask for only records that have
Ron all or any the keys in a query.
Ron,
I imagine most EAV systems allow multiple values for each
attribute - and a hstore that supported this could probably
be a pretty nice general solution for many EAV systems. IIRC
other people asked about similar on the lists before.
Well, not usually. Generally, since EAV systems are
Andrew Gierth wrote:
I have a patch almost done that adds some obvious but currently
missing functionality to hstore...
If there's any other features that people find notably missing from
hstore, I could stick them in too; any requests?
Currently hstore gives me an indexed operator to query
Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
As an hstore user, I'd be fine with simply limiting it to 64K (or, heck,
8K) and throwing an error. I'd also be fine with limiting keys to 255
bytes, although we'd have to warn people.
Yeah, 255 might well be more of a problem than the
On Mar 13, 2009, at 4:47 PM, Tom Lane wrote:
Or we could increase the size of hstore values so as to provide more
than 32 bits total for this, but that would presumably be pessimal for
all existing applications; there is evidently no one using more than
64K, or we'd have heard complaints
Tom Lane wrote:
I wrote:
If we wanted to keep the lengths in the same 32 bits they presumably
occupy now, what about splitting 8/24 (= 255 bytes for key, 24MB for
value)?
Sigh, fingers faster than brain today. A 24-bit length field could
represent lengths up to 16MB, not 24MB. Still, it
Josh Berkus j...@agliodbs.com writes:
As an hstore user, I'd be fine with simply limiting it to 64K (or, heck,
8K) and throwing an error. I'd also be fine with limiting keys to 255
bytes, although we'd have to warn people.
Yeah, 255 might well be more of a problem than the other limit. We
I have a patch almost done that adds some obvious but currently
missing functionality to hstore, specifically the ability to construct
an hstore from a record, and the ability to construct one from a pair
of arrays.
If there's any other features that people find notably missing from
hstore, I
Andrew Gierth wrote:
I have a patch almost done that adds some obvious but currently
missing functionality to hstore, specifically the ability to construct
an hstore from a record, and the ability to construct one from a pair
of arrays.
If there's any other features that people find notably
Alvaro Herrera wrote:
Andrew Gierth wrote:
I have a patch almost done that adds some obvious but currently
missing functionality to hstore, specifically the ability to construct
an hstore from a record, and the ability to construct one from a pair
of arrays.
If there's any other features that
Heikki Linnakangas wrote:
Alvaro Herrera wrote:
Andrew Gierth wrote:
I have a patch almost done that adds some obvious but currently
missing functionality to hstore, specifically the ability to construct
an hstore from a record, and the ability to construct one from a pair
of arrays.
If
On Mar 13, 2009, at 11:06 AM, Andrew Gierth wrote:
If there's any other features that people find notably missing from
hstore, I could stick them in too; any requests?
Can you create slices? That is, create a new hstore as a subset of an
existing hstore?
Also, hstore has an
Alvaro Herrera alvhe...@commandprompt.com writes:
Heikki Linnakangas wrote:
Alvaro Herrera wrote:
Optionally compressing the values would be nice ...
The whole Datum will be toasted/compressed if it gets large enough. Is
that not enough?
It doesn't always gets large enough, and there's
David E. Wheeler da...@kineticode.com writes:
On Mar 13, 2009, at 11:06 AM, Andrew Gierth wrote:
Also, hstore has an (undocumented) limit of 65535 bytes for keys and
values, and it does not behave very cleanly when given longer values
(it truncates them mod 2^16, rather than erroring). That
David == David E Wheeler da...@kineticode.com writes:
On Mar 13, 2009, at 11:06 AM, Andrew Gierth wrote:
If there's any other features that people find notably missing
from hstore, I could stick them in too; any requests?
David Can you create slices? That is, create a new hstore as a
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Tom As for truncation rather than throwing an error, I'd argue that
Tom that's a flat-out bug and the fix deserves back-patching.
Separate patch for that part then?
--
Andrew (irc:RhodiumToad)
--
Sent via pgsql-hackers mailing list
On Mar 13, 2009, at 1:21 PM, Andrew Gierth wrote:
I'm thinking that (hstore - text[]) should probably return
text[],
and maybe (hstore = text[]) returning hstore?
i.e.
select ('a=1,b=2,c=3'::hstore) - ARRAY['a','b'];
-- returns '{1,2}'
select ('a=1,b=2,c=3'::hstore) = ARRAY['a','b'];
--
David == David E Wheeler da...@kineticode.com writes:
select ('a=1,b=2,c=3'::hstore) - ARRAY['a','b'];
-- returns '{1,2}'
select ('a=1,b=2,c=3'::hstore) = ARRAY['a','b'];
-- returns 'a=1,b=2'
(by analogy to the existing operators - for lookup and = for
construction)
David Is
On Mar 13, 2009, at 2:26 PM, Andrew Gierth wrote:
David Is a more Perlish syntax out of the question?
Yes. Sorry.
David SELECT ('a=1,b=2,c=3'::hstore)['a', 'b'];
David -- returns '{1,2}'
That would require integrating hstore into core - array subscripting
isn't a user-definable operation.
David E. Wheeler da...@kineticode.com writes:
Is a more Perlish syntax out of the question?
Yes. SQL is not Perl.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Mar 13, 2009, at 2:35 PM, Tom Lane wrote:
Is a more Perlish syntax out of the question?
Yes. SQL is not Perl.
You mean all this time I thought I was writing Perl when I was using
PostgreSQL, and it turns out that it's *not* Perl? That explains the
strange lack of sigils.
Thanks
I wrote:
If we wanted to keep the lengths in the same 32 bits they presumably
occupy now, what about splitting 8/24 (= 255 bytes for key, 24MB for
value)?
Sigh, fingers faster than brain today. A 24-bit length field could
represent lengths up to 16MB, not 24MB. Still, it seems like a
Tom Lane wrote:
Or we could increase the size of hstore values so as to provide more
than 32 bits total for this, but that would presumably be pessimal for
all existing applications; there is evidently no one using more than
64K, or we'd have heard complaints before.
Would it work to allow
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane wrote:
Or we could increase the size of hstore values so as to provide more
than 32 bits total for this, but that would presumably be pessimal for
all existing applications; there is evidently no one using more than
64K, or we'd have
30 matches
Mail list logo
