attribute names & typecast/psql default port

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

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

Correct. (Unless anyone can find if it busts anything which regression
would not find?)

Thanks

Gavin

On Sat, 8 Sep 2001, Bruce Momjian wrote:

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:

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: