On Thu, Sep 27, 2012 at 04:02:45PM -0400, Robert Haas wrote:
> On Thu, Sep 27, 2012 at 2:34 PM, Magnus Hagander wrote:
> > I'm not sure that's a way we really want to go down. How do we define which
> > third party vendors would get to reserve oids? And how many? And under what
> > other potential
On Thu, Sep 27, 2012 at 10:02 PM, Robert Haas wrote:
> On Thu, Sep 27, 2012 at 2:34 PM, Magnus Hagander wrote:
>> I'm not sure that's a way we really want to go down. How do we define which
>> third party vendors would get to reserve oids? And how many? And under what
>> other potential terms?
>>
On Thu, Sep 27, 2012 at 2:34 PM, Magnus Hagander wrote:
> I'm not sure that's a way we really want to go down. How do we define which
> third party vendors would get to reserve oids? And how many? And under what
> other potential terms?
>
> Seems like we'd set ourselves up for endless discussions
On Sep 27, 2012 9:52 AM, "Robert Haas" wrote:
>
> On Wed, Sep 26, 2012 at 10:08 AM, Andrew Dunstan
wrote:
> > How many would EDB need for it to be useful?
>
> Looks like we currently have about 160 hard-coded OIDs in our fork
> that are not in PostgreSQL, across all catalogs. Actually, there are
>
> > I did like the alternative idea upthread of UUIDs for types which
> > would give them a virtually unlimited space.
>
> Yeah, me too. That doesn't require a centralized authority (hence, no
> debates here about whether a given extension is important enough to merit
> an allocation of a give
On Wed, Sep 26, 2012 at 10:08 AM, Andrew Dunstan wrote:
> How many would EDB need for it to be useful?
Looks like we currently have about 160 hard-coded OIDs in our fork
that are not in PostgreSQL, across all catalogs. Actually, there are
probably some things we could do to reduce that number, w
On Tue, Sep 25, 2012 at 5:36 PM, Peter Eisentraut wrote:
> On Mon, 2012-09-24 at 21:18 -0700, Daniel Farina wrote:
>> The gap between
>> pre-JSON-in-the-standard-library in Python, Ruby, et al and
>> post-JSON-in-stdlib was much smaller.
>
> Except in Python they renamed the thing.
By 'smaller' I
Peter Eisentraut writes:
> Here is a problem: If I write an "hstore-ng" extension, I have two
In the patch for Finer Extension Dependencies, the offer is that you
have the hstore-ng extension provide the 'hstore' feature.
https://commitfest.postgresql.org/action/patch_view?id=727
Now, that s
On 9/25/12 8:48 PM, Andrew Dunstan wrote:
> That still leaves the other uses for having well known Oids (or possibly
> UUIDs) for non-builtin types (e.g. so Drivers don't have to look them up
> in the catalogs, or having issues when types are added to the core.)
Here is a problem: If I write an "
Antonin Houska writes:
> I'm also implementing an extension where direct access to non-fixed OIDs
> (i.e. no catalog cache lookup by name) would be very helpful. I spent some
> time thinking about a workaround that makes OID registry unnecessary.
> How about the following?
> 1. Add a new varlena
On 09/25/2012 08:56 PM, Robert Haas wrote:
On Tue, Sep 25, 2012 at 10:23 AM, Tom Lane wrote:
Andrew Dunstan writes:
Given your previous comments, perhaps we could just start handing out
Oids (if there is any demand) numbered, say, 9000 and up. That should
keep us well clear of any existing u
I'm also implementing an extension where direct access to non-fixed OIDs
(i.e. no catalog cache lookup by name) would be very helpful. I spent some
time thinking about a workaround that makes OID registry unnecessary.
How about the following?
1. Add a new varlena column to pg_proc catalog table,
On 09/26/2012 02:48 AM, Andrew Dunstan wrote:
On 09/25/2012 08:35 PM, Peter Eisentraut wrote:
On Tue, 2012-09-25 at 18:22 -0400, Tom Lane wrote:
Actually, after reading another message you sent, I thought you were
going to respond that your proposed transforms feature would cover it.
I had th
On Tue, Sep 25, 2012 at 10:23 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> Given your previous comments, perhaps we could just start handing out
>> Oids (if there is any demand) numbered, say, 9000 and up. That should
>> keep us well clear of any existing use.
>
> No, I think you missed my poi
On 09/25/2012 08:35 PM, Peter Eisentraut wrote:
On Tue, 2012-09-25 at 18:22 -0400, Tom Lane wrote:
Actually, after reading another message you sent, I thought you were
going to respond that your proposed transforms feature would cover it.
I had thought about this some time ago, but it's cleare
On Mon, 2012-09-24 at 21:18 -0700, Daniel Farina wrote:
> The gap between
> pre-JSON-in-the-standard-library in Python, Ruby, et al and
> post-JSON-in-stdlib was much smaller.
Except in Python they renamed the thing.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To mak
On Tue, 2012-09-25 at 18:22 -0400, Tom Lane wrote:
> Actually, after reading another message you sent, I thought you were
> going to respond that your proposed transforms feature would cover it.
I had thought about this some time ago, but it's clearer to think of
casts as associating two types, ve
On 09/26/2012 12:06 AM, Peter Eisentraut wrote:
On 9/25/12 5:58 PM, Tom Lane wrote:
Yes ... but I really don't want to go down the path of treating those as
new type properties; it doesn't scale. (And please don't tell me that
JSON is the last word in container types and there will never be
req
On 09/25/2012 12:13 PM, Heikki Linnakangas wrote:
On 25.09.2012 12:19, Hitoshi Harada wrote:
On Tue, Sep 25, 2012 at 1:06 AM, Simon Riggs
wrote:
On 24 September 2012 21:26, Andrew Dunstan wrote:
Well, an obvious case is how record_to_json handles fields. If it
knows
nothing about the type a
Peter Eisentraut writes:
> On 9/25/12 5:58 PM, Tom Lane wrote:
>> Can we define these functions as being the cast-from-foo-to-json and
>> cast-from-foo-to-xml functions? That would let us use the existing cast
>> infrastructure to manage them.
> Sounds attractive, but there might be some problem
On 9/25/12 5:58 PM, Tom Lane wrote:
> Yes ... but I really don't want to go down the path of treating those as
> new type properties; it doesn't scale. (And please don't tell me that
> JSON is the last word in container types and there will never be
> requests for any more of these.)
Yeah, I didn
On 9/25/12 9:18 AM, Andrew Dunstan wrote:
> No, the difficulty (or at least the first difficulty) is in having the
> code recognize that it has an hstore at all. The code picks apart the
> record field by field at run time and takes various actions depending on
> the field's type. For any type it d
On 9/25/12 6:13 AM, Heikki Linnakangas wrote:
> That brings us to another question: should the cast be part of the
> hstore extension, or json? (json is built-in, but imagine for a moment
> that it was an extension, too, so that there was a choice). IIRC someone
> started a discussion on that recen
Peter Eisentraut writes:
> On 9/24/12 10:26 PM, Andrew Dunstan wrote:
>> Well, an obvious case is how record_to_json handles fields. If it knows
>> nothing about the type all it can do is output the string value. That
>> doesn't work well for types such as hstore. If it could reliably
>> recognize
On 9/25/12 1:11 AM, Hitoshi Harada wrote:
> Say, if plv8
> wants to convert hstore into a javascript object. It is arbitrary for
> users to define such a function that accepts hstore as arguments, but
> how does plv8 know the input is actually hstore?
That's what the proposed transforms feature w
On 9/24/12 11:39 PM, Tom Lane wrote:
> My recollection of the PGCon discussion is that people wanted to allow
> client-side code to hard-wire type OIDs for add-on types, in more or
> less the same way that things like JDBC know that "25" is "text".
If I write a custom uint type and want to explain
On 9/24/12 10:26 PM, Andrew Dunstan wrote:
> Well, an obvious case is how record_to_json handles fields. If it knows
> nothing about the type all it can do is output the string value. That
> doesn't work well for types such as hstore. If it could reliably
> recognize a field as an hstore it might w
Tom Lane writes:
> Andrew Dunstan writes:
>> Given your previous comments, perhaps we could just start handing out
>> Oids (if there is any demand) numbered, say, 9000 and up. That should
>> keep us well clear of any existing use.
>
> No, I think you missed my point entirely: handing out OIDs a
On Tue, Sep 25, 2012 at 09:18:30AM -0400, Andrew Dunstan wrote:
> >I'm not at all familiar with record_to_json or the json datatype,
> >but wouldn't it be appropriate to create a cast from hstore to
> >json to handle that case?
>
> No, the difficulty (or at least the first difficulty) is in having
On 09/25/2012 12:14 PM, Tom Lane wrote:
Alvaro Herrera writes:
Excerpts from Hitoshi Harada's message of mar sep 25 02:11:14 -0300 2012:
Of course you can
look up type name conlusting SysCache and see if the type name is
"hstore", but it's expensive to do it for every function invocation,
so
Alvaro Herrera writes:
> Excerpts from Hitoshi Harada's message of mar sep 25 02:11:14 -0300 2012:
>> Of course you can
>> look up type name conlusting SysCache and see if the type name is
>> "hstore", but it's expensive to do it for every function invocation,
>> so caching the hstore's oid in plv
Excerpts from Hitoshi Harada's message of mar sep 25 02:11:14 -0300 2012:
> Of course you can
> look up type name conlusting SysCache and see if the type name is
> "hstore", but it's expensive to do it for every function invocation,
> so caching the hstore's oid in plv8 is the current workaround,
On 09/25/2012 10:23 AM, Tom Lane wrote:
Andrew Dunstan writes:
Given your previous comments, perhaps we could just start handing out
Oids (if there is any demand) numbered, say, 9000 and up. That should
keep us well clear of any existing use.
No, I think you missed my point entirely: handing
Andrew Dunstan writes:
> Given your previous comments, perhaps we could just start handing out
> Oids (if there is any demand) numbered, say, 9000 and up. That should
> keep us well clear of any existing use.
No, I think you missed my point entirely: handing out OIDs at the top
of the manual as
On 09/24/2012 11:39 PM, Tom Lane wrote:
My recollection of the PGCon discussion is that people wanted to allow
client-side code to hard-wire type OIDs for add-on types, in more or
less the same way that things like JDBC know that "25" is "text".
That's not unreasonable, since the alternatives a
On 09/25/2012 06:13 AM, Heikki Linnakangas wrote:
On 25.09.2012 12:19, Hitoshi Harada wrote:
On Tue, Sep 25, 2012 at 1:06 AM, Simon Riggs
wrote:
On 24 September 2012 21:26, Andrew Dunstan wrote:
Well, an obvious case is how record_to_json handles fields. If it
knows
nothing about the type
On 25.09.2012 12:19, Hitoshi Harada wrote:
On Tue, Sep 25, 2012 at 1:06 AM, Simon Riggs wrote:
On 24 September 2012 21:26, Andrew Dunstan wrote:
Well, an obvious case is how record_to_json handles fields. If it knows
nothing about the type all it can do is output the string value. That
doesn'
On Tue, Sep 25, 2012 at 1:06 AM, Simon Riggs wrote:
> On 24 September 2012 21:26, Andrew Dunstan wrote:
>> Well, an obvious case is how record_to_json handles fields. If it knows
>> nothing about the type all it can do is output the string value. That
>> doesn't work well for types such as hstore
On 09/25/2012 04:26 AM, Andrew Dunstan wrote:
On 09/24/2012 09:37 PM, Peter Eisentraut wrote:
On Mon, 2012-09-24 at 18:59 -0400, Andrew Dunstan wrote:
This rather overdue mail arises out the developer's meeting back in
May, where we discussed an item I raised suggesting an Oid registry.
The i
On 24 September 2012 21:26, Andrew Dunstan wrote:
>
> On 09/24/2012 09:37 PM, Peter Eisentraut wrote:
>>
>> On Mon, 2012-09-24 at 18:59 -0400, Andrew Dunstan wrote:
>>>
>>> This rather overdue mail arises out the developer's meeting back in
>>> May, where we discussed an item I raised suggesting a
On Mon, Sep 24, 2012 at 8:21 PM, Tom Lane wrote:
> So, yeah, we could reserve a couple hundred OIDs for a scheme like this
> and (probably) not regret it later. But a couple thousand would scare
> me ... and I'm not exactly convinced that a couple hundred is enough,
> if there's any demand out th
On Mon, Sep 24, 2012 at 8:39 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 09/24/2012 09:37 PM, Peter Eisentraut wrote:
>>> Could you fill the rest of us in with some technical details about why
>>> this might be necessary and what it aims to achieve?
>
>> Well, an obvious case is how record
Andrew Dunstan writes:
> On 09/24/2012 09:37 PM, Peter Eisentraut wrote:
>> Could you fill the rest of us in with some technical details about why
>> this might be necessary and what it aims to achieve?
> Well, an obvious case is how record_to_json handles fields. If it knows
> nothing about the
Andrew Dunstan writes:
> On 09/24/2012 09:24 PM, Tom Lane wrote:
>> Another point to think about is that it's a few years too late to
>> guarantee that any particular OID above 16384 is unused; we can't
>> do that now without possibly breaking pg_upgrade-ability of existing
>> databases. While we
On 09/24/2012 09:24 PM, Tom Lane wrote:
Andrew Dunstan writes:
... So the proposal is to have an Oid registry, in which authors could
in effect reserve an Oid (or a couple of Oids) for a type. We would
guarantee that these Oids would be reserved in just the same way Oids
for builtins are rese
On 09/24/2012 09:37 PM, Peter Eisentraut wrote:
On Mon, 2012-09-24 at 18:59 -0400, Andrew Dunstan wrote:
This rather overdue mail arises out the developer's meeting back in
May, where we discussed an item I raised suggesting an Oid registry.
The idea came from some difficulties I encountered w
On Mon, 2012-09-24 at 18:59 -0400, Andrew Dunstan wrote:
> This rather overdue mail arises out the developer's meeting back in
> May, where we discussed an item I raised suggesting an Oid registry.
>
> The idea came from some difficulties I encountered when I did the
> backport of the JSON work w
Andrew Dunstan writes:
> ... So the proposal is to have an Oid registry, in which authors could
> in effect reserve an Oid (or a couple of Oids) for a type. We would
> guarantee that these Oids would be reserved in just the same way Oids
> for builtins are reserved, and #define symbolic consta
This rather overdue mail arises out the developer's meeting back in May,
where we discussed an item I raised suggesting an Oid registry.
The idea came from some difficulties I encountered when I did the
backport of the JSON work we did in 9.2 to 9.1, but has wider
application. Say someone writ
49 matches
Mail list logo
