Re: Plpgsql search_path issue going from 9.3 to 9.6

Поиск
Список
Период
Сортировка
От Adrian Klaver
Тема Re: Plpgsql search_path issue going from 9.3 to 9.6
Дата
Msg-id f031a511-bd49-e541-f61d-4c993047baeb@aklaver.com
обсуждение исходный текст
Ответ на Re: Plpgsql search_path issue going from 9.3 to 9.6  (George Woodring <george.woodring@iglass.net>)
Список pgsql-general
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 schema and a view 
tickets in the iss-hackers schema.

Is that what you really want?


> 
> \d public.tickets
>      Column    |           Type           |                          
> Modifiers
> --------------+--------------------------+-------------------------------------------------------------
>   ticketsid    | integer                  | not null default 
> nextval('tickets_ticketsid_seq'::regclass)
>   opendate     | timestamp with time zone | default now()
>   state        | smallint                 | default 1
>   opentech     | character varying(50)    |
>   priority     | smallint                 | default 10
>   severity     | smallint                 | default 30
>   problem      | character varying(300)   |
>   summary      | text                     |
>   parent       | integer                  |
>   remed        | boolean                  | default false
>   remed2       | boolean                  | default false
>   remed_hstart | timestamp with time zone |
>   autoclean    | boolean                  | default false
>   remoteid     | character varying        |
>   remotesync   | timestamp with time zone |
>   sla_time     | interval                 |
>   sla_alarm    | boolean                  |
> 
> \d iss-hackers.tickets
>               View "iss-hackers.tickets"
>      Column    |           Type           | Modifiers
> --------------+--------------------------+-----------
>   ticketsid    | integer                  |
>   opentech     | character varying(50)    |
>   summary      | text                     |
>   parent       | integer                  |
>   opendate     | timestamp with time zone |
>   priority     | smallint                 |
>   problem      | character varying(300)   |
>   autoclean    | boolean                  |
>   state        | smallint                 |
>   severity     | smallint                 |
>   remed        | boolean                  |
>   remed2       | boolean                  |
>   remoteid     | character varying        |
>   remotesync   | timestamp with time zone |
>   sla_time     | interval                 |
>   sla_alarm    | boolean                  |
>   remed_hstart | timestamp with time zone |
>   tableoid     | oid                      |
> 
> 
> The error message is saying column2 is not a timestamp, which the public 
> table is a timestamp for column2.  If I change my SELECT in the function 
> from SELECT * to SELECT opendate  I can fix my issue easily.
> 
> George
> iGLASS Networks
> www.iglass.net <http://www.iglass.net>
> 
> 


-- 
Adrian Klaver
adrian.klaver@aklaver.com


В списке pgsql-general по дате отправления:

Предыдущее
От: Adrian Klaver
Дата:
Сообщение: Re: Db restore Error literal carriage return found hint use \r
Следующее
От: Adrian Klaver
Дата:
Сообщение: Re: Plpgsql search_path issue going from 9.3 to 9.6