Horton
Menu

Thread

  1. Problem displaying functions and views in 7.1b3

    PostgreSQL Bugs List <pgsql-bugs@postgresql.org> — 2001-02-08T00:49:05Z

     () reports a bug with a severity of 3
The lower the number the more severe it is.

Short Description
Problem displaying functions and views in 7.1b3

Long Description
BUG REPORT
Version: 7.1 beta 3
Platform:  SuSE Linux 7.0
Installation:  Mixed; 7.0.3 & 7.1 beta parallel install
Urgency:  Cosmetic
Location: psql and pgaccess

I've noticed a problem displaying Functions and Views via PSQL in
7.1b3.  When one attempts to display views (\dv), one gets nothing. 
When one displays functions, one gets the opposite ... the command lists
*all* functions, including all builtins, not just user-defined
functions.

Both views and functions operate normally when called via sql, however.

Please note that I may, due to my parallel install, be accidentally
using ver. 7.0.3 psql with the 7.1b3 Postgres.  If so, I;d like to know.


Sample Code


No file was uploaded with this report

  2. Re: Problem displaying functions and views in 7.1b3

    Tom Lane <tgl@sss.pgh.pa.us> — 2001-02-08T01:11:16Z

    pgsql-bugs@postgresql.org writes:
> I've noticed a problem displaying Functions and Views via PSQL in
> 7.1b3.  When one attempts to display views (\dv), one gets nothing. 

This is a symptom of using 7.0.* or older psql with current server.

> When one displays functions, one gets the opposite ... the command lists
> *all* functions, including all builtins, not just user-defined
> functions.

Uh, has it ever done differently?  \df certainly appears to me to list
all functions in 7.0.*.

			regards, tom lane

  3. Re: Problem displaying functions and views in 7.1b3

    Inoue, Hiroshi <inoue@tpf.co.jp> — 2001-02-08T01:39:47Z

    Tom Lane wrote:

> 
> > When one displays functions, one gets the opposite ... the command lists
> > *all* functions, including all builtins, not just user-defined
> > functions.
> 
> Uh, has it ever done differently?  \df certainly appears to me to list
> all functions in 7.0.*.
> 

There's the following code in src/bin/pgaccess/lib/mainlib.tcl

                wpg_select $CurrentDB "select proname from pg_proc where
oid>$maxim order by proname" rec {

where maxim(the oid of "template1" database) is 1 in 7.1.

Regards,
Hiroshi Inoue

  4. Re: Problem displaying functions and views in 7.1b3

    Tom Lane <tgl@sss.pgh.pa.us> — 2001-02-08T02:12:51Z

    Hiroshi Inoue <Inoue@tpf.co.jp> writes:
> Tom Lane wrote:
>> Uh, has it ever done differently?  \df certainly appears to me to list
>> all functions in 7.0.*.

> There's the following code in src/bin/pgaccess/lib/mainlib.tcl
>                 wpg_select $CurrentDB "select proname from pg_proc where
> oid>$maxim order by proname" rec {
> where maxim(the oid of "template1" database) is 1 in 7.1.

Okay, so pgaccess has got a behavior change ... but the bug report was
about psql, or so I thought.

We can easily change pgaccess to do this correctly for 7.1, but then it
will fail completely on older releases (there was no datlastsysoid column
in pg_database before).  Is backward compatibility a design concern for
pgaccess, or not?

			regards, tom lane

  5. Re: Problem displaying functions and views in 7.1b3

    Inoue, Hiroshi <inoue@tpf.co.jp> — 2001-02-08T04:34:12Z

    Tom Lane wrote:
> 
> Hiroshi Inoue <Inoue@tpf.co.jp> writes:
> > Tom Lane wrote:
> >> Uh, has it ever done differently?  \df certainly appears to me to list
> >> all functions in 7.0.*.
> 
> > There's the following code in src/bin/pgaccess/lib/mainlib.tcl
> >                 wpg_select $CurrentDB "select proname from pg_proc where
> > oid>$maxim order by proname" rec {
> > where maxim(the oid of "template1" database) is 1 in 7.1.
> 
> Okay, so pgaccess has got a behavior change ... but the bug report was
> about psql, or so I thought.
>

Similar bug reports have been floating around ODBC, pgaccess,
psql etc and so people seem to be confused.

> We can easily change pgaccess to do this correctly for 7.1, but then it
> will fail completely on older releases (there was no datlastsysoid column
> in pg_database before).  Is backward compatibility a design concern for
> pgaccess, or not?
> 

How about the following though the result is different from
datlastsysoid ?

  select max(oid) from pg_database where datname like 'template%';

Regards,
Hiroshi Inoue

  6. Re: Problem displaying functions and views in 7.1b3

    Tom Lane <tgl@sss.pgh.pa.us> — 2001-02-08T04:39:51Z

    Hiroshi Inoue <Inoue@tpf.co.jp> writes:
> How about the following though the result is different from
> datlastsysoid ?

>   select max(oid) from pg_database where datname like 'template%';

Too lax --- suppose someone makes a database named 'template3' ?

Even if we restricted the pattern to 'template[01]', it would fail
if someone deleted and rebuilt template1, which is a supported operation
now.

If we want to do it in a backwards-compatible fashion in pgaccess,
I'd recommend trying the datlastsysoid approach and then the other
way if that fails.  I'm just wondering if anyone cares ...

			regards, tom lane

  7. Re: Problem displaying functions and views in 7.1b3

    Constantin Teodorescu <teo@flex.ro> — 2001-02-08T17:43:49Z

    ----- Original Message -----
From: "Tom Lane" <tgl@sss.pgh.pa.us>
To: "Hiroshi Inoue" <Inoue@tpf.co.jp>
Cc: <teo@flex.ro>; <pgsql-bugs@postgresql.org>
Sent: Thursday, February 08, 2001 4:12 AM
Subject: Re: [BUGS] Problem displaying functions and views in 7.1b3


> Hiroshi Inoue <Inoue@tpf.co.jp> writes:
> > Tom Lane wrote:
> >> Uh, has it ever done differently?  \df certainly appears to me to list
> >> all functions in 7.0.*.
>
> > There's the following code in src/bin/pgaccess/lib/mainlib.tcl
> >                 wpg_select $CurrentDB "select proname from pg_proc where
> > oid>$maxim order by proname" rec {
> > where maxim(the oid of "template1" database) is 1 in 7.1.
>
> Okay, so pgaccess has got a behavior change ... but the bug report was
> about psql, or so I thought.
>
> We can easily change pgaccess to do this correctly for 7.1, but then it
> will fail completely on older releases (there was no datlastsysoid column
> in pg_database before).  Is backward compatibility a design concern for
> pgaccess, or not?

We can detect the PostgreSQL version (select version();)  so we can
implement different behaviors.
if { $PG_VERSION >= 7} {
   wpg_select .....
} else {
  wpg_select ....
}

Constantin Teodorescu