Re: Reference by output in : \d <table_name>

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

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(at)postgresql(dot)org)
> To make changes to your Subscription:
> http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.org&extra=pgsql-patches

--
Bruce Momjian <bruce(at)momjian(dot)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(at)hotmail(dot)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(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "kenneth d'souza" <kd_souza(at)hotmail(dot)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.
>

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

_________________________________________________________________
Tried the new MSN Messenger? It’s cool! Download now.
http://messenger.msn.com/Download/Default.aspx?mkt=en-in

-----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(at)gmail(dot)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(at)commandprompt(dot)com> To: direvus(at)gmail(dot)com> CC: tgl(at)sss(dot)pgh(dot)pa(dot)us; kd_souza(at)hotmail(dot)com; pgsql-patches(at)postgresql(dot)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
_________________________________________________________________
Fashion Channel : Want to know what’s the latest in the fashion world ? You have it all here on MSN Fashion.
http://lifestyle.in.msn.com/

-----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-----