Re: First SVG graphic
On 07/02/2019 18:11, Jürgen Purtz wrote: >>> @@ -152,15 +156,15 @@ postgres.txt: postgres.html >>> postgres.pdf: >>> $(error Invalid target; use postgres-A4.pdf or postgres-US.pdf as >>> targets) >>> >>> -%-A4.fo: stylesheet-fo.xsl %.sgml $(ALLSGML) >>> +%-A4.fo: stylesheet-fo.xsl %.sgml >>> $(XMLLINT) $(XMLINCLUDE) --noout --valid $(word 2,$^) >>> $(XSLTPROC) $(XMLINCLUDE) $(XSLTPROCFLAGS) --stringparam paper.type A4 -o >>> $@ $(wordlist 1,2,$^) >>> >>> -%-US.fo: stylesheet-fo.xsl %.sgml $(ALLSGML) >>> +%-US.fo: stylesheet-fo.xsl %.sgml >>> $(XMLLINT) $(XMLINCLUDE) --noout --valid $(word 2,$^) >>> $(XSLTPROC) $(XMLINCLUDE) $(XSLTPROCFLAGS) --stringparam paper.type >>> USletter -o $@ $(wordlist 1,2,$^) >>> >>> -%.pdf: %.fo >>> +%.pdf: %.fo $(ALLSGML) $(SVGSRC) >>> $(FOP) -fo $< -pdf $@ >>> >> This seems a bit wrong. The .fo target does depend on ALLSGML. The >> .pdf target does not, but it presumably does depend on SVGSRC. > It's a transitive dependency: the pdf target is triggered after changes > in svg (or sgml), this triggers the fo targets. Therefore it's not > necessary to have svg (or sgml) dependencies at the fo level. If $(ALLSGML) changes, then the .fo file needs to be rebuilt. If $(SVGSRC) changes, then the .pdf file needs to be rebuilt. So those two groups of files need to be handled differently. The way you have written it, a change in $(ALLSGML) will just rebuild the .pdf file from a stale .fo. >> The variable name SVGSRC is a bit confusing. What is it the source of? > The variable SVGSRC points to all svg-files, similar to ALLSGML which > points to the sgml files. Whenever any of them changes, certain targets > will fire. Right, so maybe name it ALLSVG? >>> @@ -209,7 +213,7 @@ check: postgres.sgml $(ALLSGML) check-tabs >>> install: install-html install-man >>> >>> installdirs: >>> - $(MKDIR_P) '$(DESTDIR)$(htmldir)'/html $(addprefix >>> '$(DESTDIR)$(mandir)'/man, 1 3 $(sqlmansectnum)) >>> + $(MKDIR_P) '$(DESTDIR)$(htmldir)'/html/svg html/svg $(addprefix >>> '$(DESTDIR)$(mandir)'/man, 1 3 $(sqlmansectnum)) >>> >>> # If the install used a man directory shared with other applications, this >>> will remove all files. >>> uninstall: >> html/svg is not an installation directory. You need to create it >> somewhere else. > Please help. I haven't understood the distinction between installation > directory and DESTDIR. On the other hand, in the Makefile there is a - > redundant - command within the html-stamp target: $(MKDIR_P) html/svg. > But this will run frequently, which is not necessary. Right, so you probably don't need this change in the installdirs target at all. > There is a simple mechanism to create those list of figures: change line > 55 of stylesheet-html-common.xsl to "book toc,title,*figure*". But > the result is ugly - see attached screenshot. The list is out-of-line. > Additionally, in the future we will have many figures (and examples and > tables). This will lead to similar problems we actually faced with the > release notes. Maybe we don't need a list of figures at all? Let's just turn it off if we don't like it. > What is the problem here? Actually I don't have enough time to evaluate > it in deep. If it is an urgent problem (I have seen that the > commitfest-entry is tagged as "release 12") we shall shift the pg_dump > figure to a later release. The problem is that images don't show up in man pages, so we can't put any images in there, or it will look silly. > I think that the Backup chapter isn't a good place for this because it > does not explain the complete interaction between pg_dump, psql and restore. Then maybe it should explain it. The pg_dump man page should be strictly about pg_dump. The Backup chapter should explain how it fits together with the other tools. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Statement-level Triggers
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/11/sql-createtrigger.html Description: The behaviour is not clear for BEFORE Statement-level Trigger. This is because transition tables cannot be used. So how does one get access to the rows being affected?
Statement-level Triggers
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/11/sql-createtrigger.html Description: The AFTER Statement-level Trigger runs into infinite execution when another set of rows are affected for the same table through this trigger. Consider this use case where a table storage_locations that manages a hierarchy of storage_locations in stores, and thus having following columns (for simplicity): storage_location_id SERIAL NOT NULL PRIMARY KEY, store_id INTEGERNOT NULL, -- REFERENCES stores storage_location_nm VARCHAR (25) NOT NULL, parent_storage_location_id INTEGERNULL REFERENCES storage_locations, NULL for root storage locations storage_location_path TEXT NOT NULL I have a BEFORE ROW trigger, which updates the storage_location_path with parent's storage_location_path, if any, concatenated with its storage_location_name. This works fine - no issues. I have another AFTER UPDATE STATEMENT-level Trigger and function definitions as below (which updates the storage_path of the children): CREATE FUNCTION TRG_storage_locations_b_u_AS_DML () RETURNS TRIGGER AS $$ DECLARE v_separator VARCHAR (1) = '/'; v_cnt INT; BEGIN -- [ -- Required to prevent infinite recursion SELECT COUNT (*) INTOv_cnt FROMnew_table; IF (v_cnt > 0) THEN -- ] -- Required to prevent infinite recursion UPDATE storage_locations SET storage_location_path = COALESCE (i.storage_location_path || v_separator, '') || storage_locations.storage_location_nm FROMinsertedi JOINdeleted d ON ( i.storage_location_id = d.storage_location_id AND i.storage_location_path != d.storage_location_path ) WHERE storage_locations.parent_storage_location_id= i.storage_location_id; END IF; RETURN NULL; END $$ LANGUAGE plpgsql; CREATE TRIGGER storage_locations_b_u_AS_DML AFTER UPDATE ON storage_locations REFERENCING NEW TABLE AS inserted OLD TABLE AS deleted FOR EACH STATEMENT EXECUTE FUNCTION TRG_storage_locations_b_u_AS_DML (); Notice that the Trigger is getting called endlessly (if the number of rows in the NEW TABLE are NOT checked). I reckon if there are not any rows, what is the need to call the trigger. Or, may be, I am missing something, which I need to learn.
Re: Typo in Table 8.7 bytea Literal Escaped Octets
PG Doc comments form writes: > In "Table 8.7. bytea Literal Escaped Octets", the backslash character should > be escaped as '\\' or '\134', not '\' or '\\134'. Yup, you're right, somebody had a brain fade there. Thanks for noticing! regards, tom lane
AutoCommit statements do no work with postgresql 11.
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/11/ecpg-commands.html Description: I have a c++ library built with libpq.so, and I am trying to run the statements "SET AUTOCOMMIT TO ON" and "SET AUTOCOMMIT TO OFF". According to the docs, it looks like those statements are valid. But, I get errors for them... ERROR: unrecognized configuration parameter "autocommit" return code = PGRES_FATAL_ERROR Looking online, it seems like these autocommit statements are no longer supported past version 10. So, I'm guessing this documentation is off.
Re: AutoCommit statements do no work with postgresql 11.
PG Doc comments form writes: > I have a c++ library built with libpq.so, and I am trying to run the > statements "SET AUTOCOMMIT TO ON" and "SET AUTOCOMMIT TO OFF". According to > the docs, it looks like those statements are valid. Uh ... exactly what documentation are you looking at? PG hasn't supported server-side autocommit since 7.3.x. There is an autocommit variable in psql, but we concluded the server-side feature broke far more client code than it helped. regards, tom lane
Re: AutoCommit statements do no work with postgresql 11.
Jae Adams writes:
> The document that I'm looking at this here. I apologize for not sending
> the link. I had thought that the URL would be included automatically
> through the link on the documentation website.
> -- https://www.postgresql.org/docs/11/ecpg-sql-set-autocommit.html (shows
> the command syntax)
That is talking about an ecpg ("embedded SQL") command, which like the
psql case is a facility provided by client-side code. There is no
autocommit-off feature on the server side, and you are not using any
client library that would offer one.
(It's a bit unfortunate that ecpg's command looks exactly like
a server command, but there you have it.)
regards, tom lane
