On Dec15, 2010, at 16:34 , Jan Urbański wrote:
> On 15/12/10 16:25, Dmitriy Igrishin wrote:
>> 2010/12/15 Jan Urbański
>>> So how about just adding a text column to pg_type and a IDENTIFIER
>>> keywork to CREATE TYPE. It's not guaranteed to be unique, but isn't it
>>> pushing the argument to the e
2010/12/15 Dmitriy Igrishin :
>
>
> 2010/12/15 Florian Pflug
>>
>> On Dec15, 2010, at 18:33 , Dmitriy Igrishin wrote:
>> > 2010/12/15 Florian Pflug
>> > On Dec15, 2010, at 16:18 , Dmitriy Igrishin wrote:
>> > >> 2010/12/15 Florian Pflug
>> > >> On Dec15, 2010, at 02:14 , James William Pye wrote:
2010/12/15 Robert Haas
> On Wed, Dec 15, 2010 at 2:14 PM, Robert Haas
> wrote:
> > On Wed, Dec 15, 2010 at 1:22 PM, Dmitriy Igrishin
> wrote:
> >> Yes, but range of PostgreSQL's OIDs can be reserved. One or even ten
> >> millions, e.g. can be enough.
> >
> > No, they can't. PostgreSQL is alrea
2010/12/16 Florian Pflug
> On Dec15, 2010, at 21:28 , Dimitri Fontaine wrote:
> > Florian Pflug writes:
> >> Not if CREATE EXTENSION allows you install hstore into an arbitrary
> schema.
> >
> > It also allows you to change it after the fact, and to easily track it
> > down. Here's an updated ve
On Dec15, 2010, at 21:28 , Dimitri Fontaine wrote:
> Florian Pflug writes:
>> Not if CREATE EXTENSION allows you install hstore into an arbitrary schema.
>
> It also allows you to change it after the fact, and to easily track it
> down. Here's an updated version of the query to find the hstore ty
Florian Pflug writes:
> Not if CREATE EXTENSION allows you install hstore into an arbitrary schema.
It also allows you to change it after the fact, and to easily track it
down. Here's an updated version of the query to find the hstore type OID
reliably once we have extensions in:
dim=# SELECT t.
On tis, 2010-12-14 at 11:52 -0500, Tom Lane wrote:
> Peter Eisentraut writes:
> > On mån, 2010-12-13 at 08:50 +0100, Jan Urbański wrote:
> >> It would be cool to be able to transparently use hstores as Python
> >> dictionaries and vice versa. It would be easy enough with hstore as a
> >> core type
2010/12/15 Dmitriy Igrishin
>
>
> 2010/12/15 Pavel Stehule
>
> 2010/12/15 Dmitriy Igrishin :
>> >
>> >
>> > 2010/12/15 Florian Pflug
>> >>
>> >> On Dec15, 2010, at 18:33 , Dmitriy Igrishin wrote:
>> >> > 2010/12/15 Florian Pflug
>> >> > On Dec15, 2010, at 16:18 , Dmitriy Igrishin wrote:
>> >>
2010/12/15 Dmitriy Igrishin
>
>
> 2010/12/15 Robert Haas
>
> On Wed, Dec 15, 2010 at 2:14 PM, Robert Haas
>> wrote:
>> > On Wed, Dec 15, 2010 at 1:22 PM, Dmitriy Igrishin
>> wrote:
>> >> Yes, but range of PostgreSQL's OIDs can be reserved. One or even ten
>> >> millions, e.g. can be enough.
>>
2010/12/15 Pavel Stehule
> 2010/12/15 Dmitriy Igrishin :
> >
> >
> > 2010/12/15 Florian Pflug
> >>
> >> On Dec15, 2010, at 18:33 , Dmitriy Igrishin wrote:
> >> > 2010/12/15 Florian Pflug
> >> > On Dec15, 2010, at 16:18 , Dmitriy Igrishin wrote:
> >> > >> 2010/12/15 Florian Pflug
> >> > >> On D
On Wed, Dec 15, 2010 at 2:14 PM, Robert Haas wrote:
> On Wed, Dec 15, 2010 at 1:22 PM, Dmitriy Igrishin wrote:
>> Yes, but range of PostgreSQL's OIDs can be reserved. One or even ten
>> millions, e.g. can be enough.
>
> No, they can't. PostgreSQL is already deployed without any such
> restrictio
On Wed, Dec 15, 2010 at 1:22 PM, Dmitriy Igrishin wrote:
> Yes, but range of PostgreSQL's OIDs can be reserved. One or even ten
> millions, e.g. can be enough.
No, they can't. PostgreSQL is already deployed without any such
restriction. You can "reserve" those OIDs because they may already be
i
2010/12/15 Florian Pflug
> On Dec15, 2010, at 18:33 , Dmitriy Igrishin wrote:
> > 2010/12/15 Florian Pflug
> > On Dec15, 2010, at 16:18 , Dmitriy Igrishin wrote:
> > >> 2010/12/15 Florian Pflug
> > >> On Dec15, 2010, at 02:14 , James William Pye wrote:
> > >> > On Dec 13, 2010, at 6:16 PM, Tom
Robert Haas writes:
> Well then we need a reliable way to identify a type. What would satisfy you?
An oid ?
=# select objid
from pg_extension_objects('hstore')
where class = 'pg_type'::regclass
and objdesc ~ '(^|\.)hstore$';
objid
---
16387
(1 row)
You have 4
On Dec15, 2010, at 18:33 , Dmitriy Igrishin wrote:
> 2010/12/15 Florian Pflug
> On Dec15, 2010, at 16:18 , Dmitriy Igrishin wrote:
> >> 2010/12/15 Florian Pflug
> >> On Dec15, 2010, at 02:14 , James William Pye wrote:
> >> > On Dec 13, 2010, at 6:16 PM, Tom Lane wrote:
> >> >> how do you identify
2010/12/15 Florian Pflug
> On Dec15, 2010, at 16:18 , Dmitriy Igrishin wrote:
> >> 2010/12/15 Florian Pflug
> >> On Dec15, 2010, at 02:14 , James William Pye wrote:
> >> > On Dec 13, 2010, at 6:16 PM, Tom Lane wrote:
> >> >> how do you identify which type OID is really hstore?
> >> >
> >> > How
On Dec15, 2010, at 16:18 , Dmitriy Igrishin wrote:
>> 2010/12/15 Florian Pflug
>> On Dec15, 2010, at 02:14 , James William Pye wrote:
>> > On Dec 13, 2010, at 6:16 PM, Tom Lane wrote:
>> >> how do you identify which type OID is really hstore?
>> >
>> > How about an identification field on pg_type?
On Wed, Dec 15, 2010 at 10:15 AM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>> Wrong probem. What we need is a way to identify a type without
>> knowing in advance what its OID is. In other words, we need to
>> distinguish between the hstore type that is shipped in contrib, and
>> some stup
On 15/12/10 16:25, Dmitriy Igrishin wrote:
> 2010/12/15 Jan Urbański
>> So how about just adding a text column to pg_type and a IDENTIFIER
>> keywork to CREATE TYPE. It's not guaranteed to be unique, but isn't it
>> pushing the argument to the extreme? Someone can change around bool and
>> text ty
2010/12/15 Jan Urbański
> On 15/12/10 16:11, Tom Lane wrote:
> > Robert Haas writes:
> >> I was asking what would satisfy you as regards a reliable way to
> >> identify a type, not what you think we should do about this particular
> >> proposal.
> >
> > Okay: a preassigned OID is safe. I haven'
On 15/12/10 16:11, Tom Lane wrote:
> Robert Haas writes:
>> I was asking what would satisfy you as regards a reliable way to
>> identify a type, not what you think we should do about this particular
>> proposal.
>
> Okay: a preassigned OID is safe. I haven't seen any other safe
> proposals. Rel
2010/12/15 Florian Pflug
> On Dec15, 2010, at 02:14 , James William Pye wrote:
> > On Dec 13, 2010, at 6:16 PM, Tom Lane wrote:
> >> how do you identify which type OID is really hstore?
> >
> > How about an identification field on pg_type?
> >
> > CREATE TYPE hstore ..., IDENTIFIER 'org.postgresq
Robert Haas writes:
> Wrong probem. What we need is a way to identify a type without
> knowing in advance what its OID is. In other words, we need to
> distinguish between the hstore type that is shipped in contrib, and
> some stupid DBA who types "CREATE DOMAIN hstore as text".
Yeah, yeah. Now
Robert Haas writes:
> I was asking what would satisfy you as regards a reliable way to
> identify a type, not what you think we should do about this particular
> proposal.
Okay: a preassigned OID is safe. I haven't seen any other safe
proposals. Relying on a non-reserved name is transparently u
On Wed, Dec 15, 2010 at 10:00 AM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>> Well then we need a reliable way to identify a type. What would satisfy you?
>
> An oid ?
Wrong probem. What we need is a way to identify a type without
knowing in advance what its OID is. In other words, we ne
On Dec15, 2010, at 02:14 , James William Pye wrote:
> On Dec 13, 2010, at 6:16 PM, Tom Lane wrote:
>> how do you identify which type OID is really hstore?
>
> How about an identification field on pg_type?
>
> CREATE TYPE hstore ..., IDENTIFIER 'org.postgresql.hstore';
> -- Where the "identifier"
On Wed, Dec 15, 2010 at 9:53 AM, Tom Lane wrote:
> Robert Haas writes:
>> Well then we need a reliable way to identify a type. What would satisfy you?
>
> Either (1) do nothing (reject this whole proposal) or (2) put hstore
> in core where it will have a well-known OID. While it would be nice t
On 15/12/10 15:38, Tom Lane wrote:
> Jan =?utf-8?B?VXJiYcWEc2tp?= writes:
>> OK, here's another master plan:
>
>> 1) hstore_plplython, when loaded, looks for a type called "hstore". If
> you created a "hstore" type that does not come from hstore.so, and you
> still load hstore_plpython, you deser
Robert Haas writes:
> Well then we need a reliable way to identify a type. What would satisfy you?
Either (1) do nothing (reject this whole proposal) or (2) put hstore
in core where it will have a well-known OID. While it would be nice to
have some more-workable way to interconnect independent
On Wed, Dec 15, 2010 at 9:38 AM, Tom Lane wrote:
> Jan =?utf-8?B?VXJiYcWEc2tp?= writes:
>> OK, here's another master plan:
>
>> 1) hstore_plplython, when loaded, looks for a type called "hstore". If
> you created a "hstore" type that does not come from hstore.so, and you
> still load hstore_plpyt
Jan =?utf-8?B?VXJiYcWEc2tp?= writes:
> OK, here's another master plan:
> 1) hstore_plplython, when loaded, looks for a type called "hstore". If
you created a "hstore" type that does not come from hstore.so, and you
still load hstore_plpython, you deserve a segfault.
No, you don't. I said upthre
On Wed, Dec 15, 2010 at 12:19:53AM +0100, Jan Urbański wrote:
> Problem: what to do it hstore_plpython gets loaded, but hstore is not
> yet loaded. hstore_plpython will want to DirectFunctionCall(hstore_in),
> so loading hstore_plpython without loading hstore will result in an
> ereport(ERROR, "und
On Dec 13, 2010, at 6:16 PM, Tom Lane wrote:
> how do you identify which type OID is really hstore?
How about an identification field on pg_type?
CREATE TYPE hstore ..., IDENTIFIER 'org.postgresql.hstore';
-- Where the "identifier" is an arbitrary string.
Type information can be looked up by th
On 14/12/10 17:52, Tom Lane wrote:
> Peter Eisentraut writes:
>> On mån, 2010-12-13 at 08:50 +0100, Jan Urbański wrote:
>>> It would be cool to be able to transparently use hstores as Python
>>> dictionaries and vice versa. It would be easy enough with hstore as a
>>> core type, but with hstore as
On Dec 14, 2010, at 11:52 AM, Jan Urbański wrote:
> If the function is declared to return a hstore, it transforms the
> dictionary to a hstore.
Oh, right. Duh.
>> Can you overload the stringification of a dictionary to return the hstore
>> string representation?
>
> Mmm, interesting thought. I
On 14/12/10 18:05, David E. Wheeler wrote:
> On Dec 13, 2010, at 11:37 PM, Jan Urbański wrote:
>
>> A function said to be returning a hstore could return a dictionary and if it
>> would have only string keys/values, it would be changed into a hstore (and
>> if not, throw an ERROR).
>
> It doesn
On Dec 14, 2010, at 9:31 AM, Robert Haas wrote:
> Three different people developed patches, and I think we don't really
> have unanimity on which way to go with it. I've kind of been thinking
> we should wait for a broader consensus on which way to go with it...
There needs to be a discussion fo
Oleg Bartunov writes:
> On Tue, 14 Dec 2010, Robert Haas wrote:
>> On Tue, Dec 14, 2010 at 12:25 PM, Oleg Bartunov wrote:
>>> Just wondering about JSON, are there anyone who signed already to work on
>>> JSON or it's just a theoretical discussions ?
>> Three different people developed patches, a
Robert Haas writes:
> 2010/12/14 Andrew Dunstan :
>> On 12/14/2010 12:06 PM, Robert Haas wrote:
>>> Not exactly, because in hstore all the element values have to be,
>>> specifically, text. Having hstores of other kinds of objects would,
>>> presumably, be useful.
>> I love hstore, and I've used
On Tue, 14 Dec 2010, Robert Haas wrote:
On Tue, Dec 14, 2010 at 12:25 PM, Oleg Bartunov wrote:
Just wondering about JSON, are there anyone who signed already to work on
JSON or it's just a theoretical discussions ? If so, I agree, having JSON
properly implemented and simple wrapper for hstore
On Tue, Dec 14, 2010 at 12:25 PM, Oleg Bartunov wrote:
> Just wondering about JSON, are there anyone who signed already to work on
> JSON or it's just a theoretical discussions ? If so, I agree, having JSON
> properly implemented and simple wrapper for hstore just for compatibility,
> would
> be v
On Tue, 14 Dec 2010, Andrew Dunstan wrote:
On 12/14/2010 12:06 PM, Robert Haas wrote:
I haven't actually figured out what the benefit would be, other than
buzzword compliance and a chance to invent some random nonstandard
syntax. If the element values all have to be the same type, you've
bas
On Tue, 14 Dec 2010, Robert Haas wrote:
On Tue, Dec 14, 2010 at 11:51 AM, Tom Lane wrote:
Peter Eisentraut writes:
On m?n, 2010-12-13 at 10:55 -0500, Tom Lane wrote:
We don't normally invent specialized syntax for a specific datatype.
Not even if it's in core.
I think the idea would be t
2010/12/14 Tom Lane :
> Robert Haas writes:
>> On Tue, Dec 14, 2010 at 11:51 AM, Tom Lane wrote:
>>> If the element values all have to be the same type, you've
>>> basically got hstore.
>
>> Not exactly, because in hstore all the element values have to be,
>> specifically, text. Having hstores o
2010/12/14 Tom Lane :
> Robert Haas writes:
>> On Tue, Dec 14, 2010 at 11:51 AM, Tom Lane wrote:
>>> If the element values all have to be the same type, you've
>>> basically got hstore.
>
>> Not exactly, because in hstore all the element values have to be,
>> specifically, text. Having hstores o
2010/12/14 Andrew Dunstan :
> On 12/14/2010 12:06 PM, Robert Haas wrote:
>>>
>>> I haven't actually figured out what the benefit would be, other than
>>> buzzword compliance and a chance to invent some random nonstandard
>>> syntax. If the element values all have to be the same type, you've
>>> ba
On 12/14/2010 12:06 PM, Robert Haas wrote:
I haven't actually figured out what the benefit would be, other than
buzzword compliance and a chance to invent some random nonstandard
syntax. If the element values all have to be the same type, you've
basically got hstore.
Not exactly, because in h
Robert Haas writes:
> On Tue, Dec 14, 2010 at 11:51 AM, Tom Lane wrote:
>> If the element values all have to be the same type, you've
>> basically got hstore.
> Not exactly, because in hstore all the element values have to be,
> specifically, text. Having hstores of other kinds of objects would
On Tue, Dec 14, 2010 at 11:51 AM, Tom Lane wrote:
> Peter Eisentraut writes:
>> On mån, 2010-12-13 at 10:55 -0500, Tom Lane wrote:
>>> We don't normally invent specialized syntax for a specific datatype.
>>> Not even if it's in core.
>
>> I think the idea would be to make associative arrays a kin
On Dec 13, 2010, at 11:37 PM, Jan Urbański wrote:
> A function with a hstore parameter called x would get a Python dictionary as
> its input. A function said to be returning a hstore could return a dictionary
> and if it would have only string keys/values, it would be changed into a
> hstore (a
2010/12/14 Pavel Stehule
> 2010/12/13 Dmitriy Igrishin :
> >
> >
> > 2010/12/14 Pavel Stehule
> >>
> >> 2010/12/13 Dmitriy Igrishin :
> >> >
> >> >
> >> > 2010/12/13 Pavel Stehule
> >> >>
> >> >> 2010/12/13 Dmitriy Igrishin :
> >> >> >
> >> >> >
> >> >> > 2010/12/13 Pavel Stehule
> >> >> >>
>
Peter Eisentraut writes:
> On mÃ¥n, 2010-12-13 at 08:50 +0100, Jan UrbaÅski wrote:
>> It would be cool to be able to transparently use hstores as Python
>> dictionaries and vice versa. It would be easy enough with hstore as a
>> core type, but with hstore as an addon it's not that easy.
> I have
Peter Eisentraut writes:
> On mån, 2010-12-13 at 10:55 -0500, Tom Lane wrote:
>> We don't normally invent specialized syntax for a specific datatype.
>> Not even if it's in core.
> I think the idea would be to make associative arrays a kind of
> second-order object like arrays, instead of a data
On mån, 2010-12-13 at 08:50 +0100, Jan Urbański wrote:
> It would be cool to be able to transparently use hstores as Python
> dictionaries and vice versa. It would be easy enough with hstore as a
> core type, but with hstore as an addon it's not that easy.
I have been thinking about this class of
On mån, 2010-12-13 at 10:55 -0500, Tom Lane wrote:
> We don't normally invent specialized syntax for a specific datatype.
> Not even if it's in core.
I think the idea would be to make associative arrays a kind of
second-order object like arrays, instead of a data type.
--
Sent via pgsql-hackers
> Robert Haas writes:
> > On Mon, Dec 13, 2010 at 9:16 PM, Tom Lane wrote:
> It seems like what we need at this point is a detailed, non-arm-waving
> design for what Jan would do in pl/python if hstore were in core. Then
> we can look at it and see exactly what we'd lose from keeping hstore out
2010/12/14 Tom Lane :
> Pavel Stehule writes:
>>> On Mon, Dec 13, 2010 at 9:16 PM, Tom Lane wrote:
and (b) how do you identify which type OID
is really hstore? ("The one named hstore" is the wrong answer.)
COM architecture uses a uuid, but Microsoft leaves this idea.
can we identify
Pavel Stehule writes:
>> On Mon, Dec 13, 2010 at 9:16 PM, Tom Lane wrote:
>>> and (b) how do you identify which type OID
>>> is really hstore? Â ("The one named hstore" is the wrong answer.)
> we can search a OID function descriptor. If you know a name and
> parameter's type, then isn't a proble
2010/12/14 Robert Haas :
> On Mon, Dec 13, 2010 at 9:16 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> Can we arrange to pg_dlopen() the hstore module instead of linking
>>> against it directly? Seems like that might let you use it when
>>> available without making it a hard requirement.
>>
>> T
On Dec 13, 2010, at 7:19 PM, Robert Haas wrote:
> If we decree that Python dictionaries map
> onto hstore, does that mean they DON'T map onto json, or Pavel's
> hand-wavy proposal for associative arrays? Because from 10,000 feet
> it sure isn't obvious why hstore would be preferable to either of
On Mon, Dec 13, 2010 at 10:17 PM, Tom Lane wrote:
> I agree with that in general, but we do not have a very viable solution
> for letting independent extensions interact.
Can we create one?
> It seems like what we need at this point is a detailed, non-arm-waving
> design for what Jan would do in
Robert Haas writes:
> On Mon, Dec 13, 2010 at 9:16 PM, Tom Lane wrote:
>> That doesn't deal with the issues of (a) what is a reasonable fallback
>> when the module's not there,
> Well, if you were passed an hstore argument, and hstore can't be
> loaded, wouldn't throwing an error be fairly reaso
On Mon, Dec 13, 2010 at 9:16 PM, Tom Lane wrote:
> Robert Haas writes:
>> Can we arrange to pg_dlopen() the hstore module instead of linking
>> against it directly? Seems like that might let you use it when
>> available without making it a hard requirement.
>
> That doesn't deal with the issues
Robert Haas writes:
> Can we arrange to pg_dlopen() the hstore module instead of linking
> against it directly? Seems like that might let you use it when
> available without making it a hard requirement.
That doesn't deal with the issues of (a) what is a reasonable fallback
when the module's not
On Mon, Dec 13, 2010 at 2:50 AM, Jan Urbański wrote:
> It would be cool to be able to transparently use hstores as Python
> dictionaries and vice versa. It would be easy enough with hstore as a
> core type, but with hstore as an addon it's not that easy.
>
> There was talk about including hstore i
2010/12/13 Dmitriy Igrishin :
>
>
> 2010/12/14 Pavel Stehule
>>
>> 2010/12/13 Dmitriy Igrishin :
>> >
>> >
>> > 2010/12/13 Pavel Stehule
>> >>
>> >> 2010/12/13 Dmitriy Igrishin :
>> >> >
>> >> >
>> >> > 2010/12/13 Pavel Stehule
>> >> >>
>> >> >> 2010/12/13 Dmitriy Igrishin :
>> >> >> > There are
2010/12/14 Pavel Stehule
> 2010/12/13 Dmitriy Igrishin :
> >
> >
> > 2010/12/13 Pavel Stehule
> >>
> >> 2010/12/13 Dmitriy Igrishin :
> >> >
> >> >
> >> > 2010/12/13 Pavel Stehule
> >> >>
> >> >> 2010/12/13 Dmitriy Igrishin :
> >> >> > There are a lot of operators and functions to work with hst
2010/12/13 Dmitriy Igrishin :
>
>
> 2010/12/13 Pavel Stehule
>>
>> 2010/12/13 Dmitriy Igrishin :
>> >
>> >
>> > 2010/12/13 Pavel Stehule
>> >>
>> >> 2010/12/13 Dmitriy Igrishin :
>> >> > There are a lot of operators and functions to work with hstore.
>> >> > Does it worth it to implement similar
2010/12/13 Pavel Stehule
> 2010/12/13 Dmitriy Igrishin :
> >
> >
> > 2010/12/13 Pavel Stehule
> >>
> >> 2010/12/13 Dmitriy Igrishin :
> >> > There are a lot of operators and functions to work with hstore.
> >> > Does it worth it to implement similar things only to make it
> >> > possible using o
On Dec 13, 2010, at 8:06 AM, Oleg Bartunov wrote:
> My most serious pro about hstore in core is a better dump/restore
> support. Also, since we have so much better hstore and people started
> to use it in their projects, it'd be great to have built-in feature in
> PostgreSQL, which mimic key-va
2010/12/13 Dmitriy Igrishin :
>
>
> 2010/12/13 Pavel Stehule
>>
>> 2010/12/13 Dmitriy Igrishin :
>> > There are a lot of operators and functions to work with hstore.
>> > Does it worth it to implement similar things only to make it
>> > possible using operator [] ?
>>
>> yes
>>
>> >
>> > 2010/12/1
2010/12/13 Pavel Stehule
> 2010/12/13 Dmitriy Igrishin :
> > There are a lot of operators and functions to work with hstore.
> > Does it worth it to implement similar things only to make it
> > possible using operator [] ?
>
> yes
>
> >
> > 2010/12/13 Pavel Stehule
> >>
> >> >>
> >> >> name and
2010/12/13 Dmitriy Igrishin :
> There are a lot of operators and functions to work with hstore.
> Does it worth it to implement similar things only to make it
> possible using operator [] ?
yes
>
> 2010/12/13 Pavel Stehule
>>
>> >>
>> >> name and interface - hstore is designed as external module
There are a lot of operators and functions to work with hstore.
Does it worth it to implement similar things only to make it
possible using operator [] ?
2010/12/13 Pavel Stehule
> >>
> >> name and interface - hstore is designed as external module - a
> >> internal class can be designed differen
My most serious pro about hstore in core is a better dump/restore
support. Also, since we have so much better hstore and people started
to use it in their projects, it'd be great to have built-in feature in
PostgreSQL, which mimic key-value or document-oriented database.
Oleg
On Mon, 13 Dec
Pavel Stehule writes:
>> Could you actually name such a difference rather than pointing to some airily
>> hint of one? That would make it way much easier to see where you want to go.
> My idea is:
> somevar['key'] = value
> value = somevar['key'];
> or with constructor
> somevar = ARRAY[key1 =
>>
>> name and interface - hstore is designed as external module - a
>> internal class can be designed different.
> Could you actually name such a difference rather than pointing to some airily
> hint of one? That would make it way much easier to see where you want to go.
My idea is:
somevar['key
2010/12/13 Dmitriy Igrishin :
> Interesting argument.
> I can ask, how many people knows what is tsvector or tsquery ?
> Or how many people knows what is polygon or path ?
TSearch isn't good example. There are not a common interface for fulltext.
> The answer is: everyone who need or using it.
On Monday 13 December 2010 16:01:35 Pavel Stehule wrote:
> 2010/12/13 Andres Freund :
> > On Monday 13 December 2010 15:27:48 Pavel Stehule wrote:
> >> 2010/12/13 Dmitriy Igrishin :
> >> > Hey Pavel,
> >> >
> >> > 2010/12/13 Pavel Stehule
> >> >
> >> >> Hello
> >> >>
> >> >> this is little bit
2010/12/13 Andres Freund :
> On Monday 13 December 2010 15:27:48 Pavel Stehule wrote:
>> 2010/12/13 Dmitriy Igrishin :
>> > Hey Pavel,
>> >
>> > 2010/12/13 Pavel Stehule
>> >
>> >> Hello
>> >>
>> >> this is little bit offtopic, sorry.
>> >>
>> >> I am thinking, so we need a standard associative ar
Interesting argument.
I can ask, how many people knows what is tsvector or tsquery ?
Or how many people knows what is polygon or path ?
The answer is: everyone who need or using it.
Hstore is a proven and well designed solution. And in fact I am
surprising why it does not in core yet?!
2010/12/13
On Monday 13 December 2010 15:27:48 Pavel Stehule wrote:
> 2010/12/13 Dmitriy Igrishin :
> > Hey Pavel,
> >
> > 2010/12/13 Pavel Stehule
> >
> >> Hello
> >>
> >> this is little bit offtopic, sorry.
> >>
> >> I am thinking, so we need a standard associative array support in core
> >> - like Per
2010/12/13 Dmitriy Igrishin :
> Hey Pavel,
>
> 2010/12/13 Pavel Stehule
>>
>> Hello
>>
>> this is little bit offtopic, sorry.
>>
>> I am thinking, so we need a standard associative array support in core
>> - like Perl, Python or Javascript. So, I don't think, so migration of
>> hstore to core is g
Hey Pavel,
2010/12/13 Pavel Stehule
> Hello
>
> this is little bit offtopic, sorry.
>
> I am thinking, so we need a standard associative array support in core
> - like Perl, Python or Javascript. So, I don't think, so migration of
> hstore to core is good idea.
>
Could you tell why in-core assoc
Hello
this is little bit offtopic, sorry.
I am thinking, so we need a standard associative array support in core
- like Perl, Python or Javascript. So, I don't think, so migration of
hstore to core is good idea.
Regards
Pavel Stehule
2010/12/13 Jan Urbański :
> It would be cool to be able to t
It would be cool to be able to transparently use hstores as Python
dictionaries and vice versa. It would be easy enough with hstore as a
core type, but with hstore as an addon it's not that easy.
There was talk about including hstore in core, is there still chance for
that to happen in 9.1? I'd li
86 matches
Mail list logo
