"Dave Page" <dpage@vale-housing.co.uk> writes:
> It doesn't work quite like that anyway.
Oh, so essentially you want to simulate the namespace search on the
application side. I see.
> Anyway, current_schemas() seems ideal, thanks.
It may not be exactly what you need, because it doesn't tell you about
implicitly searched schemas --- which always includes pg_catalog and
will include a temp namespace if you've activated one. For instance,
if current_schemas claims the search path is
regression=> select current_schemas();current_schemas
-----------------{tgl,public}
(1 row)
then the real path is effectively {pg_catalog,tgl,public}, or possibly
{pg_temp_NNN,pg_catalog,tgl,public}.
There was already some discussion about making a variant version of
current_schemas() that would tell you the Whole Truth, including the
implicitly searched schemas. Seems like we'd better do that; otherwise
we'll find people hardwiring knowledge of these implicit search rules
into their apps, which is probably a bad idea.
Anyone have a preference about what to call it? I could see making a
version of current_schemas() that takes a boolean parameter, or we
could choose another function name for the implicit-schemas-too version.
>> Curious. I have not noticed much of any change in postmaster
>> startup time on Unix. Can you run a profile or something to
>> see where the time is going?
> Probably, but I'd need hand-holding as I don't have a clue how to do
> that.
I'm not sure how to do it on Cygwin, either. On Unix you'd build a
profilable backend executable usingcd pgsql/src/backendgmake cleangmake PROFILE="-pg" all
install same, run it, and then use gprof on the gmon.out file dumped
at postmaster termination. Dunno if it has to be done differently
on Cygwin.
regards, tom lane