I wrote:
Robert Haas robertmh...@gmail.com 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
On Sun, Jan 23, 2011 at 11:50 AM, Tom Lane t...@sss.pgh.pa.us 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
Robert Haas robertmh...@gmail.com writes:
On Sun, Jan 23, 2011 at 11:50 AM, Tom Lane t...@sss.pgh.pa.us 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
Tom Lane t...@sss.pgh.pa.us 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
2011/1/23 Dimitri Fontaine dimi...@2ndquadrant.fr:
Tom Lane t...@sss.pgh.pa.us 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
On Sun, Jan 23, 2011 at 4:24 PM, Joel Jacobson j...@gluefinance.com 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
On Sun, Jan 16, 2011 at 2:28 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andreas Karlsson andr...@proxel.se 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
Robert Haas robertmh...@gmail.com writes:
On Sun, Jan 16, 2011 at 2:28 PM, Tom Lane t...@sss.pgh.pa.us 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[],
On Sat, Jan 22, 2011 at 9:50 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sun, Jan 16, 2011 at 2:28 PM, Tom Lane t...@sss.pgh.pa.us wrote:
If we were to go with this, I'd be strongly tempted to rearrange all
four of the messages involved to put the
Robert Haas robertmh...@gmail.com writes:
On Sat, Jan 22, 2011 at 9:50 PM, Tom Lane t...@sss.pgh.pa.us 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
On Sat, Jan 22, 2011 at 10:13 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sat, Jan 22, 2011 at 9:50 PM, Tom Lane t...@sss.pgh.pa.us 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
2011/1/16 Tom Lane t...@sss.pgh.pa.us:
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
Joel Jacobson j...@gluefinance.com 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
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 be
Tom Lane t...@sss.pgh.pa.us writes:
Joel Jacobson j...@gluefinance.com 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
2011/1/17 Tom Lane t...@sss.pgh.pa.us:
Joel Jacobson j...@gluefinance.com 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
Andreas Karlsson andr...@proxel.se 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
On Thu, Jan 13, 2011 at 1:24 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Jan 12, 2011 at 7:47 PM, Tom Lane t...@sss.pgh.pa.us wrote:
IMO, what this patch needs is to not output the types unless they are
actually different from the default (which can
Robert Haas robertmh...@gmail.com writes:
On Thu, Jan 13, 2011 at 1:24 PM, Tom Lane t...@sss.pgh.pa.us 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
2011/1/15 Tom Lane t...@sss.pgh.pa.us:
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
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 used
On Wed, Jan 12, 2011 at 7:47 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andreas Karlsson andr...@proxel.se 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
Robert Haas robertmh...@gmail.com writes:
On Wed, Jan 12, 2011 at 7:47 PM, Tom Lane t...@sss.pgh.pa.us 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
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
Andreas Karlsson andr...@proxel.se 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
On Mon, Jan 10, 2011 at 8:56 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Jan 10, 2011 at 7:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
My point is that this isn't a bug fix, it's more like moving the
goalposts on what getObjectDescription is supposed
2011/1/11 Robert Haas robertmh...@gmail.com:
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
On Jan 11, 2011, at 8:25 AM, Joel Jacobson j...@gluefinance.com wrote:
2011/1/11 Robert Haas robertmh...@gmail.com:
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
Joel Jacobson j...@gluefinance.com 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
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
2011/1/11 Tom Lane t...@sss.pgh.pa.us:
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
On Jan11, 2011, at 16:12 , Tom Lane wrote:
Joel Jacobson j...@gluefinance.com 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
Robert Haas robertmh...@gmail.com writes:
On Mon, Jan 10, 2011 at 8:56 PM, Tom Lane t...@sss.pgh.pa.us 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
Florian Pflug f...@phlo.org 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
Joel Jacobson j...@gluefinance.com writes:
2011/1/11 Tom Lane t...@sss.pgh.pa.us:
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
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 additional
Andreas Karlsson andr...@proxel.se 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
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 input
Andreas Karlsson andr...@proxel.se 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
On Tue, Jan 11, 2011 at 7:14 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andreas Karlsson andr...@proxel.se 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
2011/1/10 Andreas Karlsson andr...@proxel.se:
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
Andreas Karlsson andr...@proxel.se 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
2011/1/10 Tom Lane t...@sss.pgh.pa.us:
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
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
Josh Berkus j...@agliodbs.com 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
On Mon, Jan 10, 2011 at 7:52 PM, Tom Lane t...@sss.pgh.pa.us 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
Robert Haas robertmh...@gmail.com writes:
On Mon, Jan 10, 2011 at 7:52 PM, Tom Lane t...@sss.pgh.pa.us 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
2011/1/11 Tom Lane t...@sss.pgh.pa.us:
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
48 matches
Mail list logo
