Seems to be on 7.3 and 7.4beta (not tested the newest - probably be next week
before I get a chance to test that).
The situation seems to be:
table public.a
function reports.f()
The function refers to "a" without the full schema (i.e. not as "public.a")
The function was originally defined with i
Richard Huxton <[EMAIL PROTECTED]> writes:
> table public.a
> function reports.f()
> The function refers to "a" without the full schema (i.e. not as "public.a")
> The function was originally defined with its name as "reports.f" while
> search_path = public...
> On dump/restore the search_path is
On Friday 03 October 2003 16:20, Tom Lane wrote:
> Richard Huxton <[EMAIL PROTECTED]> writes:
> > On dump/restore the search_path is set to reports, pg_catalog so of
> > course you get a "no relation a" error
>
> This is an SQL function right?
It was indeed.
What particularly threw me was the fac
Richard Huxton <[EMAIL PROTECTED]> writes:
>> This seems to be an additional and fairly critical reason to disable
>> checking of SQL function bodies during a reload.
> Is that what you do with views?
No. Reverse-listing of views takes the current schema path into account
when deciding whether t
Pgadmin 3.1 don t work (operations like insert rows) with columns named
in russian language (title of column in russian language). But the same
operations using PhpPgAdmin - all works very well, right. And if
replace russian title of column with equivalent in english - all works
very well.
Alexandr S wrote:
Pgadmin 3.1 don t work (operations like insert rows) with columns
named in russian language (title of column in russian language). But
the same operations using PhpPgAdmin - all works very well, right.
And if replace russian title of column with equivalent in english -
all
