Thread: attribute names & typecast/psql default port
Hi all,
I found a few bugs this afternoon - Patch attached. Patch was generated
from current source and tested with the regression tests.
...
============== shutting down postmaster ==============
======================
All 77 tests passed.
======================
...
----
Bug #1: attribute name when column is type cast:
Given the following table:
test=# \d f
Table "f"
Column | Type | Modifiers
--------+---------+-----------
i | integer |
test | text |
If I do the following:
test=# insert into f values(1,'test');
INSERT 139549 1
test=# select i::int8,test from f;
?column? | test
----------+------
1 | test
(1 row)
It doesn't make much sense that the first column should be called
'?column?'.
The patch results in the output appearing like this:
test=# select i::int8,test from f;
i | test
---+------
1 | test
(1 row)
----------
Bug #2
Found this while testing the first patch. As it happens I only have one
box handy and it was running PG already. I changed the default port to
9999. When I executed bin/psql (the freshly built psql) it connected to my
production postmaster on port 5432.
The patch sets the configured port to that defined in pg_config.h.
Gavin
Attachment
Gavin Sherry writes: > Found this while testing the first patch. As it happens I only have one > box handy and it was running PG already. I changed the default port to > 9999. When I executed bin/psql (the freshly built psql) it connected to my > production postmaster on port 5432. > > The patch sets the configured port to that defined in pg_config.h. I'm not sure I believe that, because I rely on the correct behaviour every day and I'm sure so do others. (In fact, your patch would break other things, such as the PGPORT environment variable.) The sort of problem you describe is usually caused by psql using the wrong libpq library (where the default port number is recorded). I suggest you run 'ldd psql' to see which one it picks up. -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
On Sat, 8 Sep 2001, Peter Eisentraut wrote: > Gavin Sherry writes: > > > Found this while testing the first patch. As it happens I only have one > > box handy and it was running PG already. I changed the default port to > > 9999. When I executed bin/psql (the freshly built psql) it connected to my > > production postmaster on port 5432. > > > > The patch sets the configured port to that defined in pg_config.h. > > I'm not sure I believe that, because I rely on the correct behaviour every > day and I'm sure so do others. (In fact, your patch would break other > things, such as the PGPORT environment variable.) > > The sort of problem you describe is usually caused by psql using the wrong > libpq library (where the default port number is recorded). I suggest you > run 'ldd psql' to see which one it picks up. It looks that way. My bad - thanks for pointing it out. Gavin
So bug #1 patch should be applied, and not bug #2 part? > Hi all, > > I found a few bugs this afternoon - Patch attached. Patch was generated > from current source and tested with the regression tests. > > ... > > ============== shutting down postmaster ============== > > ====================== > All 77 tests passed. > ====================== > > ... > > ---- > > Bug #1: attribute name when column is type cast: > > Given the following table: > > test=# \d f > Table "f" > Column | Type | Modifiers > --------+---------+----------- > i | integer | > test | text | > > If I do the following: > > test=# insert into f values(1,'test'); > INSERT 139549 1 > test=# select i::int8,test from f; > ?column? | test > ----------+------ > 1 | test > (1 row) > > It doesn't make much sense that the first column should be called > '?column?'. > > The patch results in the output appearing like this: > > test=# select i::int8,test from f; > i | test > ---+------ > 1 | test > (1 row) > > ---------- > > Bug #2 > > Found this while testing the first patch. As it happens I only have one > box handy and it was running PG already. I changed the default port to > 9999. When I executed bin/psql (the freshly built psql) it connected to my > production postmaster on port 5432. > > The patch sets the configured port to that defined in pg_config.h. > > Gavin Content-Description: [ Attachment, skipping... ] > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Correct. (Unless anyone can find if it busts anything which regression would not find?) Thanks Gavin On Sat, 8 Sep 2001, Bruce Momjian wrote: > > So bug #1 patch should be applied, and not bug #2 part? > > > > Hi all, > > > > I found a few bugs this afternoon - Patch attached. Patch was generated > > from current source and tested with the regression tests. > > > > ... > > > > ============== shutting down postmaster ============== > > > > ====================== > > All 77 tests passed. > > ====================== > > > > ... > > > > ---- > > > > Bug #1: attribute name when column is type cast: > > > > Given the following table: > > > > test=# \d f > > Table "f" > > Column | Type | Modifiers > > --------+---------+----------- > > i | integer | > > test | text | > > > > If I do the following: > > > > test=# insert into f values(1,'test'); > > INSERT 139549 1 > > test=# select i::int8,test from f; > > ?column? | test > > ----------+------ > > 1 | test > > (1 row) > > > > It doesn't make much sense that the first column should be called > > '?column?'. > > > > The patch results in the output appearing like this: > > > > test=# select i::int8,test from f; > > i | test > > ---+------ > > 1 | test > > (1 row) > > > > ---------- > > > > Bug #2 > > > > Found this while testing the first patch. As it happens I only have one > > box handy and it was running PG already. I changed the default port to > > 9999. When I executed bin/psql (the freshly built psql) it connected to my > > production postmaster on port 5432. > > > > The patch sets the configured port to that defined in pg_config.h. > > > > Gavin > > Content-Description: > > [ Attachment, skipping... ] > > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 4: Don't 'kill -9' the postmaster > >
First part only.
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
> Hi all,
>
> I found a few bugs this afternoon - Patch attached. Patch was generated
> from current source and tested with the regression tests.
>
> ...
>
> ============== shutting down postmaster ==============
>
> ======================
> All 77 tests passed.
> ======================
>
> ...
>
> ----
>
> Bug #1: attribute name when column is type cast:
>
> Given the following table:
>
> test=# \d f
> Table "f"
> Column | Type | Modifiers
> --------+---------+-----------
> i | integer |
> test | text |
>
> If I do the following:
>
> test=# insert into f values(1,'test');
> INSERT 139549 1
> test=# select i::int8,test from f;
> ?column? | test
> ----------+------
> 1 | test
> (1 row)
>
> It doesn't make much sense that the first column should be called
> '?column?'.
>
> The patch results in the output appearing like this:
>
> test=# select i::int8,test from f;
> i | test
> ---+------
> 1 | test
> (1 row)
>
> ----------
>
> Bug #2
>
> Found this while testing the first patch. As it happens I only have one
> box handy and it was running PG already. I changed the default port to
> 9999. When I executed bin/psql (the freshly built psql) it connected to my
> production postmaster on port 5432.
>
> The patch sets the configured port to that defined in pg_config.h.
>
> Gavin
Content-Description:
[ Attachment, skipping... ]
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
First bug patch applied, port patch skipped. Thanks. > Hi all, > > I found a few bugs this afternoon - Patch attached. Patch was generated > from current source and tested with the regression tests. > > ... > > ============== shutting down postmaster ============== > > ====================== > All 77 tests passed. > ====================== > > ... > > ---- > > Bug #1: attribute name when column is type cast: > > Given the following table: > > test=# \d f > Table "f" > Column | Type | Modifiers > --------+---------+----------- > i | integer | > test | text | > > If I do the following: > > test=# insert into f values(1,'test'); > INSERT 139549 1 > test=# select i::int8,test from f; > ?column? | test > ----------+------ > 1 | test > (1 row) > > It doesn't make much sense that the first column should be called > '?column?'. > > The patch results in the output appearing like this: > > test=# select i::int8,test from f; > i | test > ---+------ > 1 | test > (1 row) > > ---------- > > Bug #2 > > Found this while testing the first patch. As it happens I only have one > box handy and it was running PG already. I changed the default port to > 9999. When I executed bin/psql (the freshly built psql) it connected to my > production postmaster on port 5432. > > The patch sets the configured port to that defined in pg_config.h. > > Gavin Content-Description: [ Attachment, skipping... ] > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Gavin Sherry <swm@linuxworld.com.au> writes:
> It doesn't make much sense that the first column should be called
> '?column?'.
This patch is broken, since it assumes that the argument of a TypeCast
will always be an Ident.
regards, tom lane
Tom, Of course. My Bad. Attached is an updated patch with no assumption. Gavin On Sun, 16 Sep 2001, Tom Lane wrote: > Gavin Sherry <swm@linuxworld.com.au> writes: > > It doesn't make much sense that the first column should be called > > '?column?'. > > This patch is broken, since it assumes that the argument of a TypeCast > will always be an Ident. > > regards, tom lane >
Attachment
Gavin Sherry <swm@linuxworld.com.au> writes:
> Attached is an updated patch with no assumption.
I already changed it to make FigureColname recurse when presented a
TypeCast. Seems more flexible --- will deal with Attr::Typename, for
example.
regards, tom lane
Tom, Sounds like a better idea. Gavin On Sun, 16 Sep 2001, Tom Lane wrote: > Gavin Sherry <swm@linuxworld.com.au> writes: > > Attached is an updated patch with no assumption. > > I already changed it to make FigureColname recurse when presented a > TypeCast. Seems more flexible --- will deal with Attr::Typename, for > example. > > regards, tom lane >