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,
Jan =?utf-8?B?VXJiYcWEc2tp?= wulc...@wulczer.org 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.
On Wed, Dec 15, 2010 at 9:38 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Jan =?utf-8?B?VXJiYcWEc2tp?= wulc...@wulczer.org 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
Robert Haas robertmh...@gmail.com 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
On 15/12/10 15:38, Tom Lane wrote:
Jan =?utf-8?B?VXJiYcWEc2tp?= wulc...@wulczer.org 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,
On Wed, Dec 15, 2010 at 9:53 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
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 is an
On Wed, Dec 15, 2010 at 10:00 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Robert Haas robertmh...@gmail.com 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
Robert Haas robertmh...@gmail.com 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
Robert Haas robertmh...@gmail.com 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.
2010/12/15 Florian Pflug f...@phlo.org
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
On 15/12/10 16:11, Tom Lane wrote:
Robert Haas robertmh...@gmail.com 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
2010/12/15 Jan Urbański wulc...@wulczer.org
On 15/12/10 16:11, Tom Lane wrote:
Robert Haas robertmh...@gmail.com 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
On 15/12/10 16:25, Dmitriy Igrishin wrote:
2010/12/15 Jan Urbański wulc...@wulczer.org
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
On Wed, Dec 15, 2010 at 10:15 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Robert Haas robertmh...@gmail.com 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
On Dec15, 2010, at 16:18 , Dmitriy Igrishin wrote:
2010/12/15 Florian Pflug f...@phlo.org
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?
2010/12/15 Florian Pflug f...@phlo.org
On Dec15, 2010, at 16:18 , Dmitriy Igrishin wrote:
2010/12/15 Florian Pflug f...@phlo.org
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?
On Dec15, 2010, at 18:33 , Dmitriy Igrishin wrote:
2010/12/15 Florian Pflug f...@phlo.org
On Dec15, 2010, at 16:18 , Dmitriy Igrishin wrote:
2010/12/15 Florian Pflug f...@phlo.org
On Dec15, 2010, at 02:14 , James William Pye wrote:
On Dec 13, 2010, at 6:16 PM, Tom Lane wrote:
how do
Robert Haas robertmh...@gmail.com 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
2010/12/15 Florian Pflug f...@phlo.org
On Dec15, 2010, at 18:33 , Dmitriy Igrishin wrote:
2010/12/15 Florian Pflug f...@phlo.org
On Dec15, 2010, at 16:18 , Dmitriy Igrishin wrote:
2010/12/15 Florian Pflug f...@phlo.org
On Dec15, 2010, at 02:14 , James William Pye wrote:
On Dec 13,
On Wed, Dec 15, 2010 at 1:22 PM, Dmitriy Igrishin dmit...@gmail.com 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
On Wed, Dec 15, 2010 at 2:14 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Dec 15, 2010 at 1:22 PM, Dmitriy Igrishin dmit...@gmail.com 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
2010/12/15 Pavel Stehule pavel.steh...@gmail.com
2010/12/15 Dmitriy Igrishin dmit...@gmail.com:
2010/12/15 Florian Pflug f...@phlo.org
On Dec15, 2010, at 18:33 , Dmitriy Igrishin wrote:
2010/12/15 Florian Pflug f...@phlo.org
On Dec15, 2010, at 16:18 , Dmitriy Igrishin wrote:
2010/12/15 Dmitriy Igrishin dmit...@gmail.com
2010/12/15 Robert Haas robertmh...@gmail.com
On Wed, Dec 15, 2010 at 2:14 PM, Robert Haas robertmh...@gmail.com
wrote:
On Wed, Dec 15, 2010 at 1:22 PM, Dmitriy Igrishin dmit...@gmail.com
wrote:
Yes, but range of PostgreSQL's OIDs can be
2010/12/15 Dmitriy Igrishin dmit...@gmail.com
2010/12/15 Pavel Stehule pavel.steh...@gmail.com
2010/12/15 Dmitriy Igrishin dmit...@gmail.com:
2010/12/15 Florian Pflug f...@phlo.org
On Dec15, 2010, at 18:33 , Dmitriy Igrishin wrote:
2010/12/15 Florian Pflug f...@phlo.org
On
On tis, 2010-12-14 at 11:52 -0500, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net 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
Florian Pflug f...@phlo.org 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:
On Dec15, 2010, at 21:28 , Dimitri Fontaine wrote:
Florian Pflug f...@phlo.org 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
2010/12/16 Florian Pflug f...@phlo.org
On Dec15, 2010, at 21:28 , Dimitri Fontaine wrote:
Florian Pflug f...@phlo.org 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
2010/12/15 Robert Haas robertmh...@gmail.com
On Wed, Dec 15, 2010 at 2:14 PM, Robert Haas robertmh...@gmail.com
wrote:
On Wed, Dec 15, 2010 at 1:22 PM, Dmitriy Igrishin dmit...@gmail.com
wrote:
Yes, but range of PostgreSQL's OIDs can be reserved. One or even ten
millions, e.g. can be
2010/12/15 Dmitriy Igrishin dmit...@gmail.com:
2010/12/15 Florian Pflug f...@phlo.org
On Dec15, 2010, at 18:33 , Dmitriy Igrishin wrote:
2010/12/15 Florian Pflug f...@phlo.org
On Dec15, 2010, at 16:18 , Dmitriy Igrishin wrote:
2010/12/15 Florian Pflug f...@phlo.org
On Dec15, 2010,
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 wulc...@wulczer.org
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
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
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
Peter Eisentraut pete...@gmx.net 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
Peter Eisentraut pete...@gmx.net 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.
2010/12/14 Pavel Stehule pavel.steh...@gmail.com
2010/12/13 Dmitriy Igrishin dmit...@gmail.com:
2010/12/14 Pavel Stehule pavel.steh...@gmail.com
2010/12/13 Dmitriy Igrishin dmit...@gmail.com:
2010/12/13 Pavel Stehule pavel.steh...@gmail.com
2010/12/13 Dmitriy Igrishin
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 (and
On Tue, Dec 14, 2010 at 11:51 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Eisentraut pete...@gmx.net 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
Robert Haas robertmh...@gmail.com writes:
On Tue, Dec 14, 2010 at 11:51 AM, Tom Lane t...@sss.pgh.pa.us 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
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
2010/12/14 Andrew Dunstan and...@dunslane.net:
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
2010/12/14 Tom Lane t...@sss.pgh.pa.us:
Robert Haas robertmh...@gmail.com writes:
On Tue, Dec 14, 2010 at 11:51 AM, Tom Lane t...@sss.pgh.pa.us 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
2010/12/14 Tom Lane t...@sss.pgh.pa.us:
Robert Haas robertmh...@gmail.com writes:
On Tue, Dec 14, 2010 at 11:51 AM, Tom Lane t...@sss.pgh.pa.us 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
On Tue, 14 Dec 2010, Robert Haas wrote:
On Tue, Dec 14, 2010 at 11:51 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Eisentraut pete...@gmx.net 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
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
On Tue, Dec 14, 2010 at 12:25 PM, Oleg Bartunov o...@sai.msu.su 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,
On Tue, 14 Dec 2010, Robert Haas wrote:
On Tue, Dec 14, 2010 at 12:25 PM, Oleg Bartunov o...@sai.msu.su 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
Robert Haas robertmh...@gmail.com writes:
2010/12/14 Andrew Dunstan and...@dunslane.net:
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
Oleg Bartunov o...@sai.msu.su writes:
On Tue, 14 Dec 2010, Robert Haas wrote:
On Tue, Dec 14, 2010 at 12:25 PM, Oleg Bartunov o...@sai.msu.su 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
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 for
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't turn a
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 don't
On 14/12/10 17:52, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net 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
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 the
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 wulc...@wulczer.org:
It would be
Hey Pavel,
2010/12/13 Pavel Stehule pavel.steh...@gmail.com
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
2010/12/13 Dmitriy Igrishin dmit...@gmail.com:
Hey Pavel,
2010/12/13 Pavel Stehule pavel.steh...@gmail.com
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
On Monday 13 December 2010 15:27:48 Pavel Stehule wrote:
2010/12/13 Dmitriy Igrishin dmit...@gmail.com:
Hey Pavel,
2010/12/13 Pavel Stehule pavel.steh...@gmail.com
Hello
this is little bit offtopic, sorry.
I am thinking, so we need a standard associative array support in
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 Andres Freund and...@anarazel.de:
On Monday 13 December 2010 15:27:48 Pavel Stehule wrote:
2010/12/13 Dmitriy Igrishin dmit...@gmail.com:
Hey Pavel,
2010/12/13 Pavel Stehule pavel.steh...@gmail.com
Hello
this is little bit offtopic, sorry.
I am thinking, so we need a
On Monday 13 December 2010 16:01:35 Pavel Stehule wrote:
2010/12/13 Andres Freund and...@anarazel.de:
On Monday 13 December 2010 15:27:48 Pavel Stehule wrote:
2010/12/13 Dmitriy Igrishin dmit...@gmail.com:
Hey Pavel,
2010/12/13 Pavel Stehule pavel.steh...@gmail.com
Hello
2010/12/13 Dmitriy Igrishin dmit...@gmail.com:
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
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'] =
Pavel Stehule pavel.steh...@gmail.com 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
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
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 pavel.steh...@gmail.com
name and interface - hstore is designed as external module - a
internal class can be
2010/12/13 Dmitriy Igrishin dmit...@gmail.com:
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 pavel.steh...@gmail.com
name and interface - hstore is
2010/12/13 Pavel Stehule pavel.steh...@gmail.com
2010/12/13 Dmitriy Igrishin dmit...@gmail.com:
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
2010/12/13 Dmitriy Igrishin dmit...@gmail.com:
2010/12/13 Pavel Stehule pavel.steh...@gmail.com
2010/12/13 Dmitriy Igrishin dmit...@gmail.com:
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
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-value
2010/12/13 Pavel Stehule pavel.steh...@gmail.com
2010/12/13 Dmitriy Igrishin dmit...@gmail.com:
2010/12/13 Pavel Stehule pavel.steh...@gmail.com
2010/12/13 Dmitriy Igrishin dmit...@gmail.com:
There are a lot of operators and functions to work with hstore.
Does it worth it to
2010/12/13 Dmitriy Igrishin dmit...@gmail.com:
2010/12/13 Pavel Stehule pavel.steh...@gmail.com
2010/12/13 Dmitriy Igrishin dmit...@gmail.com:
2010/12/13 Pavel Stehule pavel.steh...@gmail.com
2010/12/13 Dmitriy Igrishin dmit...@gmail.com:
There are a lot of operators and
2010/12/14 Pavel Stehule pavel.steh...@gmail.com
2010/12/13 Dmitriy Igrishin dmit...@gmail.com:
2010/12/13 Pavel Stehule pavel.steh...@gmail.com
2010/12/13 Dmitriy Igrishin dmit...@gmail.com:
2010/12/13 Pavel Stehule pavel.steh...@gmail.com
2010/12/13 Dmitriy Igrishin
2010/12/13 Dmitriy Igrishin dmit...@gmail.com:
2010/12/14 Pavel Stehule pavel.steh...@gmail.com
2010/12/13 Dmitriy Igrishin dmit...@gmail.com:
2010/12/13 Pavel Stehule pavel.steh...@gmail.com
2010/12/13 Dmitriy Igrishin dmit...@gmail.com:
2010/12/13 Pavel Stehule
On Mon, Dec 13, 2010 at 2:50 AM, Jan Urbański wulc...@wulczer.org 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
Robert Haas robertmh...@gmail.com 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
On Mon, Dec 13, 2010 at 9:16 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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.
Robert Haas robertmh...@gmail.com writes:
On Mon, Dec 13, 2010 at 9:16 PM, Tom Lane t...@sss.pgh.pa.us 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
On Mon, Dec 13, 2010 at 10:17 PM, Tom Lane t...@sss.pgh.pa.us 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
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 the
2010/12/14 Robert Haas robertmh...@gmail.com:
On Mon, Dec 13, 2010 at 9:16 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
Pavel Stehule pavel.steh...@gmail.com writes:
On Mon, Dec 13, 2010 at 9:16 PM, Tom Lane t...@sss.pgh.pa.us 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
2010/12/14 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
On Mon, Dec 13, 2010 at 9:16 PM, Tom Lane t...@sss.pgh.pa.us 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
Robert Haas robertmh...@gmail.com writes:
On Mon, Dec 13, 2010 at 9:16 PM, Tom Lane t...@sss.pgh.pa.us 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
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
86 matches
Mail list logo
