Обсуждение: Reference by output in : \d
With reference to the post
http://archives.postgresql.org/pgsql-patches/2008-02/msg00104.php
and as stated by -hackers and -patchers, I am submitting the diff -c output as an attachment.
Thanks,
Kenneth
Live the life in style with MSN Lifestyle. Check out! Try it now!
http://archives.postgresql.org/pgsql-patches/2008-02/msg00104.php
and as stated by -hackers and -patchers, I am submitting the diff -c output as an attachment.
Thanks,
Kenneth
Live the life in style with MSN Lifestyle. Check out! Try it now!
Вложения
Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches It will be applied as soon as one of the PostgreSQL committers reviews and approves it. --------------------------------------------------------------------------- kenneth d'souza wrote: > > With reference to the post http://archives.postgresql.org/pgsql-patches/2008-02/msg00104.phpand as stated by -hackers and-patchers, I am submitting the diff -c output as an attachment. Thanks, Kenneth > _________________________________________________________________ > Tried the new MSN Messenger? It?s cool! Download now. > http://messenger.msn.com/Download/Default.aspx?mkt=en-in [ Attachment, skipping... ] > > -- > Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) > To make changes to your Subscription: > http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.org&extra=pgsql-patches -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
"kenneth d'souza" <kd_souza@hotmail.com> writes: > With reference to the post http://archives.postgresql.org/pgsql-patches/2008-02/msg00104.phpand as stated by -hackers and-patchers, I am submitting the diff -c output as an attachment. Thanks, Kenneth Applied with some revisions. regards, tom lane
On Mon, Mar 31, 2008 at 3:50 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > "kenneth d'souza" <kd_souza@hotmail.com> writes: > > With reference to the post http://archives.postgresql.org/pgsql-patches/2008-02/msg00104.phpand as stated by -hackersand -patchers, I am submitting the diff -c output as an attachment. Thanks, Kenneth > > Applied with some revisions. > While working on my printTable patch, I noticed that this patch only has an indent of two spaces for incoming foreign keys, while all the other table footers have an indent of four spaces. Was this deliberate? And if so, why the change in indentation for this particular listing? Cheers, BJ
Hi Brendan,
Your observation is correct.
The indentation is deliberate. The reason is that the (result7,i,3) starts with the word "FOREIGN KEY ". I am using the details that follow after this blurb.
All other keywords which are searched in usingpos = strstr(indexdef, " KEYWORD ") , the KEYWORD are embedded somewhere in between in the output. Hence indentation given is that of four spaces considering the final output that it is desired.
Thanks,
Kenneth
Windows Live Spaces : Help your online world come to life, add 500 photos a month. Try it!
Your observation is correct.
The indentation is deliberate. The reason is that the (result7,i,3) starts with the word "FOREIGN KEY ". I am using the details that follow after this blurb.
All other keywords which are searched in usingpos = strstr(indexdef, " KEYWORD ") , the KEYWORD are embedded somewhere in between in the output. Hence indentation given is that of four spaces considering the final output that it is desired.
Thanks,
Kenneth
Windows Live Spaces : Help your online world come to life, add 500 photos a month. Try it!
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, Apr 14, 2008 at 4:44 PM, kenneth d'souza wrote: > > Hi Brendan, > Your observation is correct. > > The indentation is deliberate. The reason is that the (result7,i,3) starts > with the word "FOREIGN KEY ". I am using the details that follow after this > blurb. > All other keywords which are searched in usingpos = strstr(indexdef, " > KEYWORD ") , the KEYWORD are embedded somewhere in between in the output. > Hence indentation given is that of four spaces considering the final output > that it is desired. > Sorry Kenneth, I didn't quite follow your explanation. How does the position of "FOREIGN KEY " affect the indentation at the beginning of the footer? I'm getting the following output with HEAD: """ postgres=# create table foo (a int primary key); NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "foo_pkey" for table "foo" CREATE TABLE postgres=# create table bar (a int primary key, foo int not null references foo); NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "bar_pkey" for table "bar" CREATE TABLE postgres=# alter table foo add bar int not null references bar; ALTER TABLE postgres=# \d foo Table "public.foo" Column | Type | Modifiers - --------+---------+----------- a | integer | not null Indexes: "foo_pkey" PRIMARY KEY, btree (a) Foreign-key constraints: "foo_bar_fkey" FOREIGN KEY (bar) REFERENCES bar(a) Referenced by: "bar_foo_fkey" IN bar FOREIGN KEY (foo) REFERENCES foo(a) """ Note the indent on the constraint listed under "Referenced by" is only two spaces, instead of the usual four shown under "Indexes" and "Foreign-key constraints". The attached patch corrects the indent to the standard four spaces. Cheers, BJ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: http://getfiregpg.org iD8DBQFIAz0H5YBsbHkuyV0RApFyAJ9PZNbS2p/SO0rNdKSwAjFMxWd0dwCfWd2z GMhn6Gt3ZAwelpnirDaa+1U= =Dbuo -----END PGP SIGNATURE-----
Вложения
"Brendan Jurd" <direvus@gmail.com> writes: > Sorry Kenneth, I didn't quite follow your explanation. How does the > position of "FOREIGN KEY " affect the indentation at the beginning of > the footer? I changed that patch around a bit while applying it, and very possibly fat-fingered the indentation --- I don't recall having explicitly compared it to the other cases. It surely should be consistent with everything else. regards, tom lane
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, Apr 14, 2008 at 11:42 PM, Tom Lane wrote: > "Brendan Jurd" writes: > > Sorry Kenneth, I didn't quite follow your explanation. How does the > > position of "FOREIGN KEY " affect the indentation at the beginning of > > the footer? > > I changed that patch around a bit while applying it, and very possibly > fat-fingered the indentation FWIW, I think the deviant indentation was present in the original patch submitted by Kenneth. I compared your commit with the patch, and the initial two-space indent is clearly there in both diffs. > --- I don't recall having explicitly > compared it to the other cases. It surely should be consistent with > everything else. > Yeah, that's what I figured. The patch I attached to my previous email should fix it up. Cheers, BJ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: http://getfiregpg.org iD8DBQFIA2J55YBsbHkuyV0RAjpxAKCy+pzCV8h88k5PcdwD8ik86Ka1PACffVOO K2rItDy0yWlvTxZpArpXU0o= =vLyi -----END PGP SIGNATURE-----
Brendan Jurd escribió: > Yeah, that's what I figured. The patch I attached to my previous > email should fix it up. Applied, thanks. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Hi Brendan,
I thought you were referring to the spaces sourrounding the word "FOREIGN KEY" on the last line and hence my explaination was out of place.
I am glad that you have corrected the indentation to 4 spaces. Those were unintentional at 2 spaces from myside.
However,Why does the word "FOREIGN KEY" appear in the last line of your output. My original patch had the output like this.
Referenced by:
"bar_foo_fkey" IN public.bar(foo) REFERENCES foo(a)
The keyword "FOREIGN KEY" was removed by me as it would further cause a confusion.
Secondly, since the table foo is altered with an addition of a new column "bar", it doesn't display in your output. Please double check.
My output is looking like this:
testdb=# \d foo
Table "public.foo"
Column | Type | Modifiers
--------+---------+-----------
a | integer | not null
bar | integer | not null /* Brendan--this line is missing in your output */
Indexes:
"foo_pkey" PRIMARY KEY, btree (a)
Foreign-key constraints:
"foo_bar_fkey" FOREIGN KEY (bar) REFERENCES bar(a)
Referenced by:
"bar_foo_fkey" IN public.bar(foo) REFERENCES foo(a)
/* please ignore the 2 space indent, I am still using my orignal patch. I will correct it later */
Thanks,
Kenneth
> Date: Mon, 14 Apr 2008 11:04:35 -0400
> From: alvherre@commandprompt.com
> To: direvus@gmail.com
> CC: tgl@sss.pgh.pa.us; kd_souza@hotmail.com; pgsql-patches@postgresql.org
> Subject: Re: [PATCHES] Reference by output in : \d <table_name>
>
> Brendan Jurd escribió:
>
> > Yeah, that's what I figured. The patch I attached to my previous
> > email should fix it up.
>
> Applied, thanks.
>
> --
> Alvaro Herrera http://www.CommandPrompt.com/
> PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Coolhotmail : Board of the same old Email ID’s? Get a unique one here. Try it now!
I thought you were referring to the spaces sourrounding the word "FOREIGN KEY" on the last line and hence my explaination was out of place.
I am glad that you have corrected the indentation to 4 spaces. Those were unintentional at 2 spaces from myside.
However,Why does the word "FOREIGN KEY" appear in the last line of your output. My original patch had the output like this.
Referenced by:
"bar_foo_fkey" IN public.bar(foo) REFERENCES foo(a)
The keyword "FOREIGN KEY" was removed by me as it would further cause a confusion.
Secondly, since the table foo is altered with an addition of a new column "bar", it doesn't display in your output. Please double check.
My output is looking like this:
testdb=# \d foo
Table "public.foo"
Column | Type | Modifiers
--------+---------+-----------
a | integer | not null
bar | integer | not null /* Brendan--this line is missing in your output */
Indexes:
"foo_pkey" PRIMARY KEY, btree (a)
Foreign-key constraints:
"foo_bar_fkey" FOREIGN KEY (bar) REFERENCES bar(a)
Referenced by:
"bar_foo_fkey" IN public.bar(foo) REFERENCES foo(a)
/* please ignore the 2 space indent, I am still using my orignal patch. I will correct it later */
Thanks,
Kenneth
> Date: Mon, 14 Apr 2008 11:04:35 -0400
> From: alvherre@commandprompt.com
> To: direvus@gmail.com
> CC: tgl@sss.pgh.pa.us; kd_souza@hotmail.com; pgsql-patches@postgresql.org
> Subject: Re: [PATCHES] Reference by output in : \d <table_name>
>
> Brendan Jurd escribió:
>
> > Yeah, that's what I figured. The patch I attached to my previous
> > email should fix it up.
>
> Applied, thanks.
>
> --
> Alvaro Herrera http://www.CommandPrompt.com/
> PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Coolhotmail : Board of the same old Email ID’s? Get a unique one here. Try it now!
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Apr 16, 2008 at 10:00 PM, kenneth d'souza wrote: > However,Why does the word "FOREIGN KEY" appear in the last line of your > output. My original patch had the output like this. > Referenced by: > "bar_foo_fkey" IN public.bar(foo) REFERENCES foo(a) > The keyword "FOREIGN KEY" was removed by me as it would further cause a > confusion. > Hi Kenneth, Tom reinstated the "FOREIGN KEY" part of the definition when he committed your patch. I think it's fine with "FOREIGN KEY" left in there; I don't find it confusing. I actually think it makes the line more descriptive and obvious. > Secondly, since the table foo is altered with an addition of a new column > "bar", it doesn't display in your output. Please double check. > You're right; it was just a copy-paste error I made when I was composing my email. The actual output from psql shows all columns as expected. Cheers, BJ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: http://getfiregpg.org iD8DBQFIBixv5YBsbHkuyV0RArJSAJ0eDes2V0nwlgQuNE0GjJxwW4Ey8gCgiWTw UjSjF8EJaTDSTQnkTfgSasY= =xdOl -----END PGP SIGNATURE-----