Re: Does 'instead of delete' trigger support modification of OLD
Hello Bruce, > Triggers are designed to check and modify input data, and since DELETE > has no input data, it makes no sense. Sorry, I am still ambiguous. You say that DELETE has no input data, but doc says that it has: https://www.postgresql.org/docs/current/trigger-definition.html For a row-level trigger, the input data also includes ... the OLD row for ... DELETE triggers Also restricting DELETE to change the returned data by DELETE RETURNING seems as incomplete. For example if triggers implement some compression. -- insert into field Z value -- compress and actually store Zx5 into field -- Delete this insert row -- So user should get back that the value Z was deleted and not Zx5. Correct? but currently user will see Zx5, because next code: OLD.value = uncompress( OLD.value ); does not effect RETURNING =( -- Best regards, Eugen Konkov
Re: Spanish translation of postgresql manuals
On Wed, Jan 1, 2020 at 09:38:32PM +, PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/10/index.html > Description: > > I am translating the Postgresql 10.11 manual into Spanish. Yes, someone is > interested in this, to contact me. Thank you. Great. I didn't realize we had no Spanish version, but a check on our website doesn't show any Spanish version: https://www.postgresql.org/docs/ I am sure there is a huge need for this. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Re: pg_ctl in Windows
On Thu, Jan 2, 2020 at 03:22:10AM +, PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/12/app-pg-ctl.html > Description: > > Could it be added that in Windows pg_ctl needs to be run as administrator? I > spent a lot of time trying to figure out why the program didn't run, before > I found the answer online. We don't have a lot of operating-spefic text in our docs, so a better solution might be to issue an error message suggesting the cause. What command are you running and what does the failure look like? -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Re: doc: Add anchors in create_table.sgml
On Fri, Jan 3, 2020 at 10:35:20AM -0300, Alvaro Herrera wrote: > Hi, > > On 2020-Jan-02, helix84 wrote: > > > Hi, I prefer to bookmark docs pointing to the exact term I need and > > with pg docs it's often been the case that the exact term doesn't have > > an anchor or only has unstable, generated anchors. So I would very > > much like to add stable anchors in many more places. I haven't > > contributed to pg before, so this patch is me testing the waters. If > > there is interest, I'd like to add stable anchors to wherever we'll > > agree it makes sense - preferably in an automated or semi-automated > > way. > > > > I read an older thread on this topic [1] which links to a custom SGML > > parser in Python for this specific task [2]. I have experience with > > XSLT, but not so much with SGML processing, so I would appreciate if > > you could point me whether a custom parser is the way to go for this > > task or I should look into a more generic SGML processing tool. > > Ah, > https://www.postgresql.org/message-id/aanlktikagiyyfwy_2zj8gafoc7zflgv5icdab1l7v...@mail.gmail.com > (We prefer our own archive to GMane's.) That thread is so old that > Peter feels the need to point out that the Git mirror was out of date > with CVS ... I can no longer even remember the commit process for CVS > anymore. We also converted from SGML to XML in the meantime, so you can > probably make do with a standard XML parser without having to write a > custom SGML one. (Daniele Varrazzo's patch ended up as 477319829c2e.) > > TBH I've felt the need for anchors for tags in the > past also (IIRC the runtime-config page would be improved by them), > but I'm not sure about adding them to every single keyword of every > single reference page. Is that really useful? It would be helpful if the release notes could point to specific tables in the docs, rather than just sections. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Re: Argument 'week' not supported in date_trunc function with intervals
On Fri, Jan 3, 2020 at 12:31:27PM +, PG Doc comments form wrote:
> The following documentation comment has been logged on the website:
>
> Page: https://www.postgresql.org/docs/12/functions-datetime.html
> Description:
>
> In the documentation of the date_trunc function (9.9.2), the first argument
> (field) cannot be 'week' if the second argument (source) is an interval:
>
> csauer=# SELECT DATE_TRUNC('week', INTERVAL '7 days');
>
>
>
> ERROR: interval units "week" not supported because months usually have
> fractional weeks
> csauer=# SELECT DATE_TRUNC('week', INTERVAL '1 week');
>
>
>
> ERROR: interval units "week" not supported because months usually have
> fractional weeks
>
> The documentation should state that explicitly.
>
> I also think the error message could be improved, because in the cases above
> there are no months involved and the result should be 1.
Uh, we could modify the code so that we allow SELECT DATE_TRUNC('week',
INTERVAL '') to work if there is no month component, since interval is
made up of months, days, and time. However, this would mean the
function would work with some interval values, and not others. Is that
an improvement?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
Re: References between initdb and pg_controldata
On Sat, Jan 4, 2020 at 10:10:08AM +, Paul Weiss wrote: > As with other see-alsos in Part VI, I think it would be useful to have > see-alsos between initdb and pg_controldata. Currently the pg_controldata page > at least mentions initdb, but the initdb page does not mention pg_controldata. Uh, most people who use initdb don't care about pg_controldata, but if you are studying pg_controldata, you should know that initdb created it. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Re: Making the first few chapters of Part III more novice-friendly
On Sat, Jan 4, 2020 at 10:13:54AM +, Paul Weiss wrote: > The intro to Part III says "The first few chapters are written so they can be > understood without prerequisite knowledge, so new users who need to set up > their own server can begin their exploration with this part." With that in > mind, could chapters on installation and chapters 18 & 19 be made more > novice-friendly? > > For example, consider adding a brief chapter before chapter 16 on installation > in general, explaining the options in general, the pros and cons of each, and > a > link to https://www.postgresql.org/download/. Or add those things to Section > 1.1 in part I . It says "If you are installing PostgreSQL yourself, then refer > to Chapter 16 for instructions on installation", but chapter 16 is only really > about installation from source code. > > The intro to chapter 16 also states "If you are building PostgreSQL for > Microsoft Windows, read this chapter if you intend to build with MinGW or > Cygwin; but if you intend to build with Microsoft's Visual C++, see Chapter 17 > instead." A novice might infer from that that those are the only 2 options, > rather than knowing about the much-easier-to-install binary version. Another > example is at the top 18.1. It would be nice to have a brief explanation what > a > server daemon is, or if nothing else, a link to the Wikipedia article. > > It would be great to make these chapters more friendly to PostgreSQL novices > who are Windows users. Windows (for non-developers) doesn't use the concept of > file ownership, and uses "user account" differently, so explanations of those > would be helpful. The second paragraph begins "To add a Unix user account to > your system", but nothing about Windows or macOS (I think many Mac users do > not > know it is based on UNIX). In the first paragraph of 18.2 talks about > initializing a storage area, but "initializing" is not a term regularly used > by > Windows users. In the third sentence of the second paragraph it would be > helpful to either add a Windows example, or at least say something like "There > is no default, although in UNIX popular locations include > /usr/local/pgsql/data > and /var/lib/pgsql/data." (Related, it would also be nice in section 3 of the > preface to note that most commands in the manual are given in UNIX, and that > in > Windows you would use backslashes rather than forward slashes in, for example, > path names.) While 18.3 has specific content for 5 UNIX varieties, there is no > specific content for Windows. > > I am happy to help develop solutions for any of the comments I send out. There is no question that our tutorials and novice stuff is lacking. We are very good with reference material. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
