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
25 matches
Mail list logo
