2011/1/10 Tom Lane :
> There was never any intention that that code produce a guaranteed-unique
> identifier; it's only meant to be a humanly useful identifer, and this
> patch seems to me to mostly add noise.
For all objects, except for these pg_amproc regclass, the function
does already generate
Andreas Karlsson writes:
> Here is the bug-fix patch again with a description of the context so I
> can add it to the commit fest.
> Joel Jacobson discovered a bug in the function pg_describe_object where
> it does not produce unique identifiers for some entries in pg_amproc.
There was never any
2011/1/10 Andreas Karlsson :
> Here is the bug-fix patch again with a description of the context so I
> can add it to the commit fest.
Many thanks for fixing the bug!
I also implemented the pg_describe_object in pure SQL, for those of us
who have not yet switched to PostgreSQL 9 in the production
Here is the bug-fix patch again with a description of the context so I
can add it to the commit fest.
Joel Jacobson discovered a bug in the function pg_describe_object where
it does not produce unique identifiers for some entries in pg_amproc.
This patch fixes the bug where when two entries in pg
On Sat, Jan 8, 2011 at 8:02 PM, Joel Jacobson wrote:
> 2011/1/9 Robert Haas :
>> Oops. I misread your query. I thought the duplicates were because
>> you were feeding pg_describe_object the same classoid, objoid,
>> objsubid pair more than once, but I see now that's not the case (UNION
>> != UNI
2011/1/9 Robert Haas :
> Oops. I misread your query. I thought the duplicates were because
> you were feeding pg_describe_object the same classoid, objoid,
> objsubid pair more than once, but I see now that's not the case (UNION
> != UNION ALL).
Ah, I see, yes, the query should actually be UNION
2011/1/9 Andreas Karlsson :
> Here is a patch, but I am not sure I am not sure if I like my idea for
> format. What do you think?
>
> SELECT pg_describe_object('pg_amproc'::regclass,oid,0)
> FROM pg_amproc WHERE oid IN (10608,10612);
> pg_de
Here is a patch, but I am not sure I am not sure if I like my idea for
format. What do you think?
SELECT pg_describe_object('pg_amproc'::regclass,oid,0)
FROM pg_amproc WHERE oid IN (10608,10612);
pg_describe_object
On Sat, Jan 8, 2011 at 4:21 PM, Joel Jacobson wrote:
> 2011/1/8 Robert Haas :
>> I don't think your analysis is correct. Each entry in pg_depend
>> represents the fact that one object depends on another object, and an
>> object could easily depend on more than one other object, or be
>> depended
On Sat, 2011-01-08 at 22:21 +0100, Joel Jacobson wrote:
> 2011/1/8 Robert Haas :
> > I don't think your analysis is correct. Each entry in pg_depend
> > represents the fact that one object depends on another object, and an
> > object could easily depend on more than one other object, or be
> > dep
2011/1/8 Robert Haas :
> I don't think your analysis is correct. Each entry in pg_depend
> represents the fact that one object depends on another object, and an
> object could easily depend on more than one other object, or be
> depended upon by more than one other object, or depend on one object
On Sat, Jan 8, 2011 at 12:41 PM, Joel Jacobson wrote:
> The query below should not return any rows, because if it does, then
> there are oids with non-unique descriptions.
I don't think your analysis is correct. Each entry in pg_depend
represents the fact that one object depends on another objec
2011/1/8 Magnus Hagander :
> Yes. Once things are committed to the main repository, they are only
> backed out if someone finds a major issue with them that is not
> fixable (ina reasonable timeframe). That almost never happens. We
> don't keep unapproved patches or development branches in the main
On Sat, Jan 8, 2011 at 14:05, Joel Jacobson wrote:
> 2011/1/8 Dimitri Fontaine :
>> http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=6cc2deb86e9183262493a6537700ee305fb3e096
>
> Nice! Has the patch been accepted and will be made available in future
> versions of pg?
Yes. Once thi
2011/1/8 Dimitri Fontaine :
> http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=6cc2deb86e9183262493a6537700ee305fb3e096
Nice! Has the patch been accepted and will be made available in future
versions of pg?
Also, why return NULL for pinned objects? They can also be described
usin
Robert Haas writes:
> I guess the point is that if this gets committed as a core function
> written in C, we don't need any other implementations. But I don't
> recall ever seeing a commit for that one go by...
http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=6cc2deb86e9183262
On Sat, Jan 8, 2011 at 1:59 AM, Joel Jacobson wrote:
> 2011/1/7 Jim Nasby :
>> BTW, if you're looking at making pg_depnd easier to use, see
>> http://archives.postgresql.org/message-id/129774-sup-2...@alvh.no-ip.org
>
> I guess there are more than one ways to do it, C, sql, plperl, plpgsql. :
2011/1/7 Jim Nasby :
> BTW, if you're looking at making pg_depnd easier to use, see
> http://archives.postgresql.org/message-id/129774-sup-2...@alvh.no-ip.org
I guess there are more than one ways to do it, C, sql, plperl, plpgsql. :)
I guess at least one of the methods should be provided in t
On Jan 7, 2011, at 1:46 PM, Tom Lane wrote:
> Joel Jacobson writes:
>> The function obj_unique_identifier(oid) will return a unique name for _any_
>> oid.
>
> Surely this is broken by design? You can *not* assume that the same OID
> isn't in use for different things in different system catalogs
The function should take both classid and oid as input. I'll fix.
Sent from my iPhone
On 7 jan 2011, at 20:59, Joel Jacobson wrote:
> Sent from my iPhone
>
> On 7 jan 2011, at 20:46, Tom Lane wrote:
>
>> Joel Jacobson writes:
>>> The function obj_unique_identifier(oid) will return a unique na
Sent from my iPhone
On 7 jan 2011, at 20:46, Tom Lane wrote:
> Joel Jacobson writes:
>> The function obj_unique_identifier(oid) will return a unique name for _any_
>> oid.
>
> Surely this is broken by design? You can *not* assume that the same OID
> isn't in use for different things in differ
Joel Jacobson writes:
> The function obj_unique_identifier(oid) will return a unique name for _any_
> oid.
Surely this is broken by design? You can *not* assume that the same OID
isn't in use for different things in different system catalogs. They're
only guaranteed unique within a catalog. T
22 matches
Mail list logo
