app_sessions is a table and app_users_vw is not hiding anything from you : tenant_id tenant_name tenant_shortname reseller_id user_id user_failedlogins user_fname user_lname user_email user_phone user_passwd user_seed user_hidden user_candelete user_newseed user_lastupdate tenant_lastupdate On 5 February 2015 at 23:38, David Johnston <david.g.johnston@xxxxxxxxx> wrote: > On Thu, Feb 5, 2015 at 4:29 PM, Tim Smith <randomdev4+postgres@xxxxxxxxx> > wrote: >> >> You're most welcome to look at my view definition view if you don't >> believe me .... >> >> View definition: >> SELECT a.session_id, >> a.session_ip, >> a.session_user_agent, >> a.session_start, >> a.session_lastactive, >> b.user_id, >> b.tenant_id, >> b.reseller_id, >> b.tenant_name, >> b.user_fname, >> b.user_lname, >> b.user_email, >> b.user_phone, >> b.user_seed, >> b.user_passwd, >> b.user_lastupdate, >> b.tenant_lastupdate >> FROM app_sessions a, >> app_users_vw b >> WHERE a.user_id = b.user_id; > > > So that view and definition are correct. > > So either PostgreSQL is seeing a different view (in a different schema) or > the function is confused in ways difficult to predict. > > I guess it is possible that: > > (SELECT v_row FROM v_row) would give that message but I get a "relation > v_row does not exist" error when trying to replicate the scenario. > > It may even be a bug but since you have not provided a self-contained test > case, nor the version of PostgreSQL, the assumption is user error. > > David J. > -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
