Re: Plpgsql search_path issue going from 9.3 to 9.6

2018-11-13 Thread Ravi Krishna
> > I apologize for top posting, Google hid all of the other stuff. > It is only me who thinks that when it comes to destroying email as a communication tool, no one did a better job than effing gmail.

Re: Plpgsql search_path issue going from 9.3 to 9.6

2018-11-13 Thread George Woodring
I apologize for top posting, Google hid all of the other stuff. George iGLASS Networks www.iglass.net >> >>

Re: Plpgsql search_path issue going from 9.3 to 9.6

2018-11-13 Thread George Woodring
CREATE OR REPLACE VIEW tickets AS SELECT *, tableoid FROM public.tickets WHERE ( ticketsid IN (SELECT ticketsid FROM machtick)); iGLASS Networks www.iglass.net On Tue, Nov 13, 2018 at 10:32 AM Adrian Klaver wrote: > On 11/13/18 6:54 AM, George

Re: Plpgsql search_path issue going from 9.3 to 9.6

2018-11-13 Thread Adrian Klaver
On 11/13/18 6:54 AM, George Woodring wrote: The tickets view restricts which tickets can be seen by the schema. 9.3 must have created the view in the same column order as the table (which is the case looking at one of our 9.3 databases which we have not updated yet), which is why we never saw

Re: Plpgsql search_path issue going from 9.3 to 9.6

2018-11-13 Thread George Woodring
The tickets view restricts which tickets can be seen by the schema. 9.3 must have created the view in the same column order as the table (which is the case looking at one of our 9.3 databases which we have not updated yet), which is why we never saw the issue before. George iGLASS Networks www.ig

Re: Plpgsql search_path issue going from 9.3 to 9.6

2018-11-13 Thread Adrian Klaver
On 11/13/18 6:27 AM, George Woodring wrote: I think the issue is that the function is not putting the data into the tickets%ROWTYPE correctly.  When I do \d on public.tickets and iss-hackers.tickets, the columns are in a different order. The error message is saying column2 is not a timesta

Re: Plpgsql search_path issue going from 9.3 to 9.6

2018-11-13 Thread Adrian Klaver
On 11/13/18 6:27 AM, George Woodring wrote: I think the issue is that the function is not putting the data into the tickets%ROWTYPE correctly.  When I do \d on public.tickets and iss-hackers.tickets, the columns are in a different order. That is because you have a table tickets in the public s

Re: Plpgsql search_path issue going from 9.3 to 9.6

2018-11-13 Thread George Woodring
I think the issue is that the function is not putting the data into the tickets%ROWTYPE correctly. When I do \d on public.tickets and iss-hackers.tickets, the columns are in a different order. \d public.tickets Column| Type | Modifiers --+--

Re: Plpgsql search_path issue going from 9.3 to 9.6

2018-11-13 Thread Adrian Klaver
On 11/13/18 5:17 AM, George Woodring wrote: We are having an issue with one of our plpgsql functions after migrating from 9.3 to 9.6.  The function works fine until you change the search path. psql (9.6.10) Type "help" for help. woody=> select ticket_summary(8154);                           t

Re: Plpgsql search_path issue going from 9.3 to 9.6

2018-11-13 Thread Pavel Stehule
Hi út 13. 11. 2018 v 14:18 odesílatel George Woodring < george.woodr...@iglass.net> napsal: > We are having an issue with one of our plpgsql functions after migrating > from 9.3 to 9.6. The function works fine until you change the search path. > > psql (9.6.10) > Type "help" for help. > > woody=

Plpgsql search_path issue going from 9.3 to 9.6

2018-11-13 Thread George Woodring
We are having an issue with one of our plpgsql functions after migrating from 9.3 to 9.6. The function works fine until you change the search path. psql (9.6.10) Type "help" for help. woody=> select ticket_summary(8154); ticket_summary --