In message <[EMAIL PROTECTED]>, Tom Lane avows:
%--- Begin Cite ---%
> But if they do have their own .psqlrc, doesn't that mean that you fail
> to apply the change you need?  It seems like this mechanism doesn't

If they have their own, then I trust them to do what they want (ie they can
then add the set search_path themselves). 

> achieve the results you actually want.  Wouldn't setting search_path via
> PGOPTIONS be as effective if not more so?

Ah! Perhaps. I'm actually not our postgres guy. I actually work on the core
part of our software. I just got the job of trying to put it all together
and .psqlrc hack seemed a reasonable way of accomplishing something I
thought was useful.

However the point of allowing a site to make /etc/psqlrc the global psqlrc
isn't a bad one too (and I even came up with this a couple of days ago --
don't know why I forgot to mention it....) although I guessing that the
site could set PGOPTIONS globally as easily as they could set PSQLRC.

OTOH, there certainly is something to be said simply for the following:
it's a very simple hack which fits in nicely in the code. It provides an
option to postgres users which someone out there might find useful even if
we can't come up with a convincing argument right now. It seems to me that
when I first got into sysadmin games back in the late '80's, this was the
prevailing attitude.

But I certainly look into the PGOPTIONS thing; I'd prefer not to have to
support any local hacks if I don't have to :-)


>                       regards, tom lane
%--- End Cite ---%      

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
      joining column's datatypes do not match

Reply via email to