Re: The contents of the pg_timezone_names view bring some surprises

> t...@sss.pgh.pa.us wrote: > >> adrian.kla...@aklaver.com wote: >> >>> Bryn wrote: >>> >>> (1) In the context of discussing timezones, the English word "abbreviation" >>> maps to two distinct notions in PG: "pg_timezone_names.abbre

Re: The contents of the pg_timezone_names view bring some surprises

Adrian Klaver writes: > On 5/22/21 5:52 PM, Bryn Llewellyn wrote: >> (1) In the context of discussing timezones, the English word >> "abbreviation" maps to two distinct notions in PG: >> "pg_timezone_names.abbrev"; and "pg_timezone_abbrevs.abbrev". Tom >> earlier said « there are two views [bec

Re: Postgres prepare statement caching issue in postgres command line

On 5/23/21 12:04 AM, Soumya Prasad Ukil wrote: postgres=> execute parallel_execute1('a', 'b'); postgres=> execute parallel_execute2(1, 2); I have enabled pg_stats_statement chrome extension. I have enabled postgres log inside post_parse_analyze_hook and also debugging through gdb using break

Re: The contents of the pg_timezone_names view bring some surprises

On 5/22/21 5:52 PM, Bryn Llewellyn wrote: Tom, David, Adrian, and Peter—thank you all very much for taking an interest in my questions. Your responses have, collectively, been an enormous help. I deleted the text of the exchanges in this particular branch of the overall discussion because it's

Re: Postgres prepare statement caching issue in postgres command line

postgres=> execute parallel_execute1('a', 'b');postgres=> execute parallel_execute2(1, 2); I have enabled pg_stats_statement chrome extension. I have enabled postgres log inside post_parse_analyze_hook  and also debugging through gdb using break point. I see it is always going through parse call