Thread: Problem displaying functions and views in 7.1b3
() 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
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
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
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
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
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
----- 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