Re: [HACKERS] pg_dump and search_path

Steve Thames wrote: > Thank you gentlemen for clarifying this. > > I found this problem when my database modeling tool saw a change in the > database (the nextval() parameters) after a database restore. > I guess the tool must be reading adsrc for this information. You can tell for sure by settin

Re: [HACKERS] pg_dump and search_path

Lane [mailto:t...@sss.pgh.pa.us] Sent: Tuesday, August 11, 2015 10:41 AM To: Alvaro Herrera Cc: Steve Thames; pgsql-hackers@postgresql.org Subject: Re: [HACKERS] pg_dump and search_path Alvaro Herrera writes: > Don't ever rely on adsrc. It's useless. Use pg_get_expr(adbin) >

Re: [HACKERS] pg_dump and search_path

Alvaro Herrera writes: > Don't ever rely on adsrc. It's useless. Use pg_get_expr(adbin) > instead. That's safe, for instance, if the sequence gets renamed. It's probably past time we got rid of that column altogether. It just wastes space and cycles. There was an argument for not being too q

Re: [HACKERS] pg_dump and search_path

Steve Thames wrote: >SELECT a.attnum, n.nspname, c.relname, d.adsrc AS default_value > FROM pg_attribute AS a > JOIN pg_class AS c ON a.attrelid = c.oid > JOIN pg_namespace AS n ON c.relnamespace = n.oid > LEFT JOIN pg_attrdef AS d ON d.adrelid = c.oid AND d.a

Re: [HACKERS] pg_dump and search_path

Robert Haas writes: > On Mon, Aug 10, 2015 at 1:10 PM, Steve Thames wrote: >> Please consider making the arbitrary determination of search_path by pg_dump >> an optional behavior. Or better yet, just have it generate a backup that >> accurately reflects the database it is backing up. > Hmm, I do

Re: [HACKERS] pg_dump and search_path

On Mon, Aug 10, 2015 at 1:10 PM, Steve Thames wrote: > Please consider making the arbitrary determination of search_path by pg_dump > an optional behavior. Or better yet, just have it generate a backup that > accurately reflects the database it is backing up. Hmm, I don't think it's a question of

[HACKERS] pg_dump and search_path

I earliest reference I found to this issue is here and refers to the search_path being arbitrarily set in the file created by pg_dump. This is apparently still the case in 9.4. I found this issue b