On Sun, Jan 23, 2011 at 4:24 PM, Joel Jacobson wrote:
> In the aftermath, I realized I was almost about to feel a bit ashamed
> about the fact my original forum post probably gave birth to the most
> long lived discussion in the history of PostgreSQL.
I think you'd need another order of magnitude
2011/1/23 Dimitri Fontaine :
> Tom Lane writes:
>> But anyway, this patch has now officially
>> been discussed to death.
>
> +1 :)
+∞ :)
In the aftermath, I realized I was almost about to feel a bit ashamed
about the fact my original forum post probably gave birth to the most
long lived discus
Tom Lane writes:
> But anyway, this patch has now officially
> been discussed to death.
+1 :)
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your sub
Robert Haas writes:
> On Sun, Jan 23, 2011 at 11:50 AM, Tom Lane wrote:
>> So I guess I'm coming around to the idea that we want something not too
>> much bigger than Andreas' original patch, but applying to both amop and
>> amproc, and putting the operator/function description at the end.
> Tha
On Sun, Jan 23, 2011 at 11:50 AM, Tom Lane wrote:
> And yet ... and yet ... if you adopt the position that what we're going
> to print is "amproc item: referenced procedure", then it's not entirely
> clear why the amproc item description shouldn't be complete. The
> argument that it's redundant wi
I wrote:
> Robert Haas writes:
>> We're trying to represent the pg_amproc entry here, and including a
>> bunch of details of the pg_proc entry to which it happens to point
>> seems almost better to be confusing the issue.
> Yeah, that occurred to me too. However, the CREATE OPERATOR CLASS
> synt
On Sat, Jan 22, 2011 at 10:13 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sat, Jan 22, 2011 at 9:50 PM, Tom Lane wrote:
>>> So I don't want to give up the details of the function
>>> or operator. But sticking them at the end after a colon might make it
>>> clearer that the func/operator is
Robert Haas writes:
> On Sat, Jan 22, 2011 at 9:50 PM, Tom Lane wrote:
>> So I don't want to give up the details of the function
>> or operator. But sticking them at the end after a colon might make it
>> clearer that the func/operator is referenced by the amproc or amop
>> entry, but is not the
On Sat, Jan 22, 2011 at 9:50 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Jan 16, 2011 at 2:28 PM, Tom Lane wrote:
>>> If we were to go with this, I'd be strongly tempted to rearrange all
>>> four of the messages involved to put the operator or function name
>>> at the end, eg
>>>
>>> fu
Robert Haas writes:
> On Sun, Jan 16, 2011 at 2:28 PM, Tom Lane wrote:
>> If we were to go with this, I'd be strongly tempted to rearrange all
>> four of the messages involved to put the operator or function name
>> at the end, eg
>>
>> function 1 (oidvector[], oidvector[]) of operator family ar
On Sun, Jan 16, 2011 at 2:28 PM, Tom Lane wrote:
> Andreas Karlsson writes:
>> On Sat, 2011-01-15 at 10:36 -0500, Tom Lane wrote:
>>> But I can read the handwriting on the wall: if I want this done right,
>>> I'm going to have to do it myself.
>
>> Do I understand you correctly if I interpret wha
2011/1/17 Tom Lane :
> Joel Jacobson writes:
>> a) pg_describe_object should always include the schema in the name,
>> even for object in public and pg_catalog.
>
> I knew you were going to demand that next, as soon as you figured out
> that it was an obstacle for using pg_describe_object output a
Tom Lane writes:
> Joel Jacobson writes:
>> a) pg_describe_object should always include the schema in the name,
>> even for object in public and pg_catalog.
>
> I knew you were going to demand that next, as soon as you figured out
> that it was an obstacle for using pg_describe_object output as
On Sun, 2011-01-16 at 14:28 -0500, Tom Lane wrote:
> One other point here is that I find messages like this a mite
> unreadable:
>
> function 1 (oidvector[], oidvector[]) btoidvectorcmp(oidvector,oidvector) of
> operator family array_ops for access method gin
>
> If we were to go with this, I'd
Joel Jacobson writes:
> a) pg_describe_object should always include the schema in the name,
> even for object in public and pg_catalog.
I knew you were going to demand that next, as soon as you figured out
that it was an obstacle for using pg_describe_object output as a
globally unique identifier
2011/1/16 Tom Lane :
> Comments?
I think it's great you undertook the challenge of solving this problem
the "proper way".
I think your desire to achieve perfection in every little detail is admirable.
Your patch is according to me, not far from perfect, but could be
improved in a faw ways:
a) pg
Andreas Karlsson writes:
> On Sat, 2011-01-15 at 10:36 -0500, Tom Lane wrote:
>> But I can read the handwriting on the wall: if I want this done right,
>> I'm going to have to do it myself.
> Do I understand you correctly if I interpret what you would like to see
> is the same format used now in
On Sat, 2011-01-15 at 10:36 -0500, Tom Lane wrote:
> But I can read the handwriting on the wall: if I want this done right,
> I'm going to have to do it myself.
>
> regards, tom lane
Do I understand you correctly if I interpret what you would like to see
is the same format u
2011/1/15 Tom Lane :
> But I can read the handwriting on the wall: if I want this done right,
> I'm going to have to do it myself.
>
> regards, tom lane
Excellently put! I will with pride steal that phrase and use it
whenever I run into the same situation myself.
Quite often
Robert Haas writes:
> On Thu, Jan 13, 2011 at 1:24 PM, Tom Lane wrote:
>> Read the CREATE OPERATOR CLASS source code. (It likely would be best to
>> refactor that a bit so it would expose some way to obtain the implied
>> defaults --- I don't think that's done explicitly now, and it's
>> certain
On Thu, Jan 13, 2011 at 1:24 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Jan 12, 2011 at 7:47 PM, Tom Lane wrote:
>>> IMO, what this patch needs is to not output the types unless they are
>>> actually different from the default (which can be inferred from the AM
>>> type and the functio
Robert Haas writes:
> On Wed, Jan 12, 2011 at 7:47 PM, Tom Lane wrote:
>> IMO, what this patch needs is to not output the types unless they are
>> actually different from the default (which can be inferred from the AM
>> type and the function arguments). That would fix my concern about it
>> emit
On Wed, Jan 12, 2011 at 7:47 PM, Tom Lane wrote:
> Andreas Karlsson writes:
>> Here is a very simple change of the patch to make the output look more
>> like the syntax of ALTER OPERATOR FAMILY to improve consistency.
>
> IMO, what this patch needs is to not output the types unless they are
> act
Andreas Karlsson writes:
> Here is a very simple change of the patch to make the output look more
> like the syntax of ALTER OPERATOR FAMILY to improve consistency.
IMO, what this patch needs is to not output the types unless they are
actually different from the default (which can be inferred fro
Here is a very simple change of the patch to make the output look more
like the syntax of ALTER OPERATOR FAMILY to improve consistency.
Before patch:
function 1 bttextcmp(text,text) of operator family array_ops for access method
gin
With the first version:
function 1 bttextcmp(text,text) of op
On Tue, Jan 11, 2011 at 7:14 PM, Tom Lane wrote:
> Andreas Karlsson writes:
>> On Tue, 2011-01-11 at 14:01 -0500, Tom Lane wrote:
>>> It really shouldn't be useful to include those. Attend what it says in
>>> the fine manual for CREATE OPERATOR CLASS:
>
>> Hm, that is not what I see when reading
Andreas Karlsson writes:
> On Tue, 2011-01-11 at 14:01 -0500, Tom Lane wrote:
>> It really shouldn't be useful to include those. Attend what it says in
>> the fine manual for CREATE OPERATOR CLASS:
> Hm, that is not what I see when reading the source.
> There can exist several entries in pg_amp
On Tue, 2011-01-11 at 14:01 -0500, Tom Lane wrote:
> It really shouldn't be useful to include those. Attend what it says in
> the fine manual for CREATE OPERATOR CLASS:
>
> In a FUNCTION clause, the operand data type(s) the function is
> intended to support, if different from the inpu
Andreas Karlsson writes:
> So would anyone be confused by a description of pg_amproc not including
> the types?
It really shouldn't be useful to include those. Attend what it says in
the fine manual for CREATE OPERATOR CLASS:
In a FUNCTION clause, the operand data type(s) the function i
On Tue, 2011-01-11 at 11:43 -0500, Tom Lane wrote:
> If that's what you're after, getObjectDescription is entirely
> unsuitable, because of the fact that its results are dependent
> on search path and language settings.
>
> regards, tom lane
Agreed, and as long as the additi
Joel Jacobson writes:
> 2011/1/11 Tom Lane :
>> Seems like concatenating the OIDs would accomplish that. (If you
>> think not, well, you still haven't explained what problem you're trying
>> to solve...)
> The can be different in two different databases sharing the same
> original schema, but of
Florian Pflug writes:
> @OP: Wouldn't it be sufficient to provide such a thing for structure
> objects that people are actually going to modify on a regular basis?
Yeah, I still don't see the need to argue over whether the elements of
an operator class are uniquely identifiable or not.
Robert Haas writes:
> On Mon, Jan 10, 2011 at 8:56 PM, Tom Lane wrote:
>> Not really. AFAIR, there are two cases that exist in practice,
>> depending on which AM you're talking about:
>>
>> 1. The recorded types match the input types of the operator/function
>> (btree & hash).
>> 2. The recor
On Jan11, 2011, at 16:12 , Tom Lane wrote:
> Joel Jacobson writes:
>> I instead propose we introduce a new function named
>> pg_get_object_unique_identifier( classid oid, objid oid, objsubid
>> integer ) returns text.
>
> Seems like concatenating the OIDs would accomplish that. (If you
> think n
2011/1/11 Tom Lane :
> Seems like concatenating the OIDs would accomplish that. (If you
> think not, well, you still haven't explained what problem you're trying
> to solve...)
The can be different in two different databases sharing the same
original schema, but of two different versions.
In this
Excerpts from Robert Haas's message of mar ene 11 10:52:12 -0300 2011:
> Well, we shouldn't change them randomly or arbitrarily, but improving them is
> another thing altogether. I think the contention that any user or
> application anywhere is depending on the exact textual representation of a
Joel Jacobson writes:
> I instead propose we introduce a new function named
> pg_get_object_unique_identifier( classid oid, objid oid, objsubid
> integer ) returns text.
Seems like concatenating the OIDs would accomplish that. (If you
think not, well, you still haven't explained what problem you
On Jan 11, 2011, at 8:25 AM, Joel Jacobson wrote:
> 2011/1/11 Robert Haas :
>> I don't get it. If two different items that exist in the system out
>> of the box have the same description, it seems clear that relevant
>> piece of disambiguating information exists nowhere in the description
>> stri
2011/1/11 Robert Haas :
> I don't get it. If two different items that exist in the system out
> of the box have the same description, it seems clear that relevant
> piece of disambiguating information exists nowhere in the description
> string.
I guess it is a question of prioritization.
If backw
On Mon, Jan 10, 2011 at 8:56 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Jan 10, 2011 at 7:52 PM, Tom Lane wrote:
>>> My point is that this isn't a bug fix, it's more like moving the
>>> goalposts on what getObjectDescription is supposed to do.
>
>> I think that adding the types to the
2011/1/11 Tom Lane :
> It would make dependency error messages significantly longer and less
> readable. Quite aside from the point at hand here, we elide schema
> names in many cases (and it looks like there are some code paths where
> getObjectDescription never bothers to print them at all). An
Robert Haas writes:
> On Mon, Jan 10, 2011 at 7:52 PM, Tom Lane wrote:
>> My point is that this isn't a bug fix, it's more like moving the
>> goalposts on what getObjectDescription is supposed to do.
> I think that adding the types to the description string is a pretty
> sensible thing to do.
N
On Mon, Jan 10, 2011 at 7:52 PM, Tom Lane wrote:
> It would make dependency error messages significantly longer and less
> readable. Quite aside from the point at hand here, we elide schema
> names in many cases (and it looks like there are some code paths where
> getObjectDescription never bothe
Josh Berkus writes:
>> 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.
> Would making the identifier unique do any *harm*?
It would make dependency error m
> 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.
Would making the identifier unique do any *harm*?
--
-- Josh Berkus
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
49 matches
Mail list logo
