Get original view definition without modification
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/9.5/rules-views.html Description: I am looking a way to get exact view definition, for ex : CREATE TABLE t1(id int,name varchar); INSERT INTO t1 values(1,'n1'),(2,'n2'); CREATE VIEW v2 AS SELECT * FROM t1 WHERE name = 'n1'; But when i checked the definition in postgresql DB(9.5) in pg_views table, it is getting modified in the below way : postgres=# select * from pg_views where schemaname = 'sc1' and viewname = 'v2'; schemaname | viewname | viewowner | definition +--+---+- sc1| v2 | postgres | SELECT t1.id, + | | | t1.name + | | |FROM sc1.t1 + | | | WHERE ((t1.name)::text = 'n1'::text); I am fine with adding tablename before columnname but i don't want the extra '::text' part. Is there anyway to achieve this(like any other system table i can query from to get original definition)
Re: descriptions of pg_stat_user_functions and pg_stat_slru
On 2020/05/27 12:17, Fujii Masao wrote: On 2020/05/25 14:23, Fujii Masao wrote: On 2020/05/22 22:35, Fujii Masao wrote: On 2020/05/21 4:53, Tom Lane wrote: Fujii Masao writes: On 2020/05/20 22:32, Tom Lane wrote: OK by me --- that, too, would be more like the existing catalogs chapter. Yeah, so I'd like to propose the attached patch. Hmmm ... I'm not exactly convinced about sticking xreflabels onto the s as you've done here. Presumably that would make s render like "pg_stat_slru" not "Section 27.2.3", which I think is not consistent with our practice elsewhere. I'd be inclined to leave the id attributes on the s, and add xreflabels there if we want them. I see that catalogs.sgml doesn't really match either of those approaches, though. Not sure if we want to change it. It looks like people have tended to use to substitute text for xref's to the catalog sections, so maybe it would be better to add xreflabels there too and simplify the references. Yeah, since I think that using is simpler than , I added xlabel in . But if we don't do that for the consistency with catalog.sgml, I think that there are two approaches. (1) Replace with when referencing to the monitoring views docs. For example, add and replace with . (2) Leave as it is. In this case, for example, references to the table of pg_stat_replication instead of the section. I prefer (1) because it's better to reference to the section rather than the table. There are thirty for monitoring views in the docs and they need to be updated. Attached (monitoring_docfix_v2.patch) is the patch for (1). Barring any objection, I will commit this patch. Pushed. Thanks! Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION
Re: max_wal_size
David, I don't know whether a change along those lines to the configuration reference page is useful or not - I wouldn't make one without a comprehensive re-read of the actual background/learning section of the documentation. My gut instinct is that I just don't think the documentation can do this situation justice and that, as illustrated by this thread, there are better resources available for these less common situations. Hm, After some cool down period, I looked with a fresh look. I'm sure there is no need to make changes to the configuration reference page. And I'm not sure that there is a need to make changes to the main section. In any case, it was interesting discussion. Thank you. - Pavel Luzanov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
Re: Get original view definition without modification
PG Doc comments form writes: > I am looking a way to get exact view definition, for ex : > ... > I am fine with adding tablename before columnname but i don't want the extra > '::text' part. Is there anyway to achieve this(like any other system table i > can query from to get original definition) No, Postgres only saves a "compiled" form of a view. Storing the original text would have its own pitfalls, eg what if you rename a table or column mentioned in the view? (Also, the SQL standard has some requirements that would be difficult to meet otherwise.) If you really want the original text, best bet is to keep your schema creation commands in a VCS or the like, outside the database. regards, tom lane
