On Tuesday 12 May 2009 08:36:20 Khee Chin wrote:
> postgres=# \di idx_foo_bt_fooi;
> List of relations
> Schema | Name | Type | Owner | Table | Method |
> Definition
> +-+---+---+---++
On May 19, 2009, at 10:52 AM, Robert Haas wrote:
How 'bout we flip that around? :-)
+1
(BTW, I know there's pg_dump, but being able to get SQL out of psql
is just a lot more convenient)
--
Decibel!, aka Jim C. Nasby, Database Architect deci...@decibel.org
Give your computer some brain ca
On May 19, 2009, at 11:31 AM, decibel wrote:
On May 19, 2009, at 10:27 AM, Tom Lane wrote:
Robert Haas writes:
On May 19, 2009, at 10:02 AM, Greg Stark >
wrote:
One advantage of the current arrangement is that the constraints
and
triggers are almost (though not quite) in the same form as
decibel writes:
> On May 19, 2009, at 10:27 AM, Tom Lane wrote:
>> +1 --- I *very* often find myself copying-and-pasting from \d output,
>> and the proposed tabular format would be a huge step backwards for
>> that. Personally I kinda wish that the column display were closer
>> to what CREATE TAB
On May 19, 2009, at 10:27 AM, Tom Lane wrote:
Robert Haas writes:
On May 19, 2009, at 10:02 AM, Greg Stark
wrote:
One advantage of the current arrangement is that the constraints and
triggers are almost (though not quite) in the same form as the
command to create them. It would be sad to lo
Robert Haas writes:
> On May 19, 2009, at 10:02 AM, Greg Stark
> wrote:
>> One advantage of the current arrangement is that the constraints and
>> triggers are almost (though not quite) in the same form as the
>> command to create them. It would be sad to lose that competely.
> Agreed.
+1
On May 19, 2009, at 10:02 AM, Greg Stark
wrote:
One advantage of the current arrangement is that the constraints and
triggers are almost (though not quite) in the same form as the
command to create them. It would be sad to lose that competely.
Agreed. What I most often want to do is eit
One advantage of the current arrangement is that the constraints and
triggers are almost (though not quite) in the same form as the command
to create them. It would be sad to lose that competely.
Is there any room for a compromise? Something that just reduces the
clutter incrementally inste
On May 19, 2009, at 9:41 AM, decibel wrote:
On May 18, 2009, at 10:25 PM, Tom Lane wrote:
decibel writes:
The gripe I have with \d is that the "footnotes" are very hard to
scan through once you have more than a few things on a table. What
I'd like to see is a version that provides the same i
On May 18, 2009, at 10:25 PM, Tom Lane wrote:
decibel writes:
The gripe I have with \d is that the "footnotes" are very hard to
scan through once you have more than a few things on a table. What
I'd like to see is a version that provides the same information, but
in a tabular output.
Hmm, I'm
decibel writes:
> The gripe I have with \d is that the "footnotes" are very hard to
> scan through once you have more than a few things on a table. What
> I'd like to see is a version that provides the same information, but
> in a tabular output.
Hmm, I'm not visualizing what you have in mi
On May 8, 2009, at 3:43 PM, Alvaro Herrera wrote:
Well, you can see that with \d on the table, but IMHO this should be
present on \di too, so +1.
One gripe I had with \d and indexes the other day is that it sucks on
functional indexes -- it just says "pg_expression_1".
The gripe I have with \
Khee Chin writes:
> My sincere apologies for flooding your mailboxes once again, as the
> patch attached in the previous post was incorrect. Also, I had failed
> to show test-cases of \d in both 8.4 and 8.3 servers.
This is still modifying the behavior of \di, which I thought was not
wanted.
My sincere apologies for flooding your mailboxes once again, as the
patch attached in the previous post was incorrect. Also, I had failed
to show test-cases of \d in both 8.4 and 8.3 servers.
Attached are the test cases for psql connecting to 8.4 and 8.3.
psql (8.4beta1)
Type "help" for help.
p
>> On Tue, May 12, 2009 at 12:20 AM, Tom Lane wrote:
>>>
>>> Index "public.fooi"
>>> Column | Type | Definition
>>> -+-+
>>> f1 | integer | f1
>>> pg_expression_2 | integer | (f2+f3)
>
Hi,
I'd agree that the mucking around wi
Greg Stark writes:
> On Tue, May 12, 2009 at 12:20 AM, Tom Lane wrote:
>>
>> Index "public.fooi"
>> Column | Type | Definition
>> -+-+
>> f1 | integer | f1
>> pg_expression_2 | integer | (f2+f3)
> Is there any reason to expo
On Tue, May 12, 2009 at 12:20 AM, Tom Lane wrote:
>
> Index "public.fooi"
> Column | Type | Definition
> -+-+
> f1 | integer | f1
> pg_expression_2 | integer | (f2+f3)
Is there any reason to expose "pg_expression_2" to the use
Alvaro Herrera writes:
> Khee Chin escribió:
>> Updated with an additional line in the comments for get_indexdef
>>
>> * if colno == -999, we only want the name of the variables that
>> make up the index
> I don't think this hack is going to fly.
Yeah ... if it were local in describe.c tha
Khee Chin escribió:
> Updated with an additional line in the comments for get_indexdef
>
> * if colno == -999, we only want the name of the variables that
> make up the index
I don't think this hack is going to fly. I suggest you need to find
some other way to implement this.
--
Alvaro He
Updated with an additional line in the comments for get_indexdef
* if colno == -999, we only want the name of the variables that
make up the index
Apologies for leaving this out in my earlier post.
Regards,
Khee Chin.
index.patch
Description: Binary data
--
Sent via pgsql-hackers mailin
On Sun, May 10, 2009 at 3:59 AM, Alvaro Herrera
wrote:
> Yeah. (I note that the expressions are already shown as footers when
> you display the table instead of the index. It seems like the \d code
> for indexes did not get updated when that new code was added.)
Made some changes to the patch t
Tom Lane escribió:
> David Fetter writes:
> > On Fri, May 08, 2009 at 04:43:44PM -0400, Alvaro Herrera wrote:
> >> One gripe I had with \d and indexes the other day is that it sucks
> >> on functional indexes -- it just says "pg_expression_1".
>
> > Any ideas for a better naming convention?
>
>
David Fetter writes:
> On Fri, May 08, 2009 at 04:43:44PM -0400, Alvaro Herrera wrote:
>> One gripe I had with \d and indexes the other day is that it sucks
>> on functional indexes -- it just says "pg_expression_1".
> Any ideas for a better naming convention?
Changing the naming convention seem
On Fri, May 08, 2009 at 04:43:44PM -0400, Alvaro Herrera wrote:
> Ricardo Bessa escribió:
> > Hi,
> >
> > I think that can be useful the command \di on psql show the method of
> > index (hash, btree, ...) like:
> >
> > test=# \di
> >List of relations
> > S
>
> Please add it to wiki.postgresql.org/wiki/CommitFestInProgress
>
Submitted under http://wiki.postgresql.org/wiki/CommitFest_2009-First#Clients
Regards,
Khee Chin.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresq
Khee Chin escribió:
> > Hi,
>
> > I think that can be useful the command \di on psql show the method of
> > index (hash, btree, ...) like:
>
> > test=# \di
> >List of relations
> > Schema | Name | Type | Owner| Table | Method
> > -
> Hi,
> I think that can be useful the command \di on psql show the method of
> index (hash, btree, ...) like:
> test=# \di
>List of relations
> Schema | Name | Type | Owner| Table | Method
> +---+---+--
Ricardo Bessa escribió:
> Hi,
>
> I think that can be useful the command \di on psql show the method of
> index (hash, btree, ...) like:
>
> test=# \di
>List of relations
> Schema | Name | Type | Owner| Table | Method
> +--
Hi,
I think that can be useful the command \di on psql show the method of
index (hash, btree, ...) like:
test=# \di
List of relations
Schema | Name | Type | Owner| Table | Method
+---+---+++--
29 matches
Mail list logo
