Re: [HACKERS] Postgres service stops when I kill client backend on Windows
Hello Dmitry > -Original Message- > From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Dmitry Vasilyev > Sent: Freitag, 9. Oktober 2015 11:52 > To: pgsql-hackers@postgresql.org > Subject: [HACKERS] Postgres service stops when I kill client backend on > Windows > > I’ve started PostgreSQL server on Windows and then I kill client > backend’s process by taskkill the service was stopped: > > postgres=# select pg_backend_pid(); > pg_backend_pid > >1976 > > postgres=# \! taskkill /pid 1976 /f > SUCCESS: The process with PID 1976 has been terminated. > postgres=# select 1; > server closed the connection unexpectedly > This probably means the server terminated abnormally > before or while processing the request. > The connection to the server was lost. Attempting reset: Failed. > !> > > > If I kill backend’s process on Linux then service not failing. So > what’s the problem? Why PostgreSQL is so strange on Windows? I can't say what happens on windows, but I don't undestand either why you want to kill the session you are in. Besides that why don't you use pg_terminate_backend? db=> select pg_backend_pid(); pg_backend_pid 8808 (1 row) db=> select pg_terminate_backend(8808); FATAL: terminating connection due to administrator command server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. The connection to the server was lost. Attempting reset: Succeeded. db=> select pg_backend_pid(); pg_backend_pid 8500 (1 row) Regards Charles > > > -- > Dmitry Vasilyev > Postgres Professional: http://www.postgrespro.com > The Russian Postgres Company > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Odd query execution behavior with extended protocol
Hello > Npgsql supports sending multiple SQL statements in a single packet via the > extended protocol. This works fine, but when the second query SELECTs a value > modified by the first's UPDATE, I'm getting a result as if the > UPDATE hasn't yet occurred. Looks like the first updating statement is not committed, assuming that the two statements run in different transactions. > The exact messages send by Npgsql are: > > Parse (UPDATE data SET name='foo' WHERE id=1), statement=unnamed > Describe (statement=unnamed) > Bind (statement=unnamed, portal=MQ0) > Parse (SELECT * FROM data WHERE id=1), statement=unnamed > Describe (statement=unnamed) > Bind (statement=unnamed, portal=MQ1) > Execute (portal=MQ0) > Close (portal=MQ0) > Execute (portal=MQ1) > Close (portal=MQ1) > Sync I never used Npgsql so I don't know if there is something missing there. Would you need an explicit commit before closing MQ0? Also I am not in clear what "statement=unnamed" means, but it is used twice. Is it possible that the update is overwritten with select before it executes? Just some thoughts, as I said I know nothing of Npgsql. BTW: Do you see the change after update in your DB if you look into it with another tool (e.g. psql)? Charles -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] unclear about row-level security USING vs. CHECK
I had not seen this. > -Original Message- > From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas > Sent: Montag, 28. September 2015 21:43 > To: Stephen Frost <sfr...@snowman.net> > Cc: Peter Eisentraut <pete...@gmx.net>; pgsql-hackers > <pgsql-hackers@postgresql.org>; Charles Clavadetscher > <clavadetsc...@swisspug.org> > Subject: Re: [HACKERS] unclear about row-level security USING vs. CHECK > > On Mon, Sep 28, 2015 at 3:15 PM, Stephen Frost <sfr...@snowman.net> wrote: > > I listed out the various alternatives but didn't end up getting any > > responses to it. I'm still of the opinion that the documentation is the > > main thing which needs improving here, but we can also change CREATE > > POLICY, et al, to require an explicit WITH CHECK clause for the commands > > where that makes sense if that's the consensus. > > My vote is to remove the behavior where USING flows over to WITH > CHECK. So you only get a WITH CHECK policy if you explicitly specify > one. > > If there's some other consensus, OK, but tempus fugit. If the behaviof of USING doesn't flow to WITH CHECK is the same as making WITH CHECK mandatory for ALL and UPDATE, I guess. Otherwise there would be a partially unspecified behavior. Or am I misunderstanding your idea? Charles -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] unclear about row-level security USING vs. CHECK
Good morning > -Original Message- > From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Stephen Frost > Sent: Montag, 28. September 2015 21:16 > To: Peter Eisentraut <pete...@gmx.net>; Robert Haas <robertmh...@gmail.com> > Cc: pgsql-hackers <pgsql-hackers@postgresql.org>; Charles Clavadetscher > <clavadetsc...@swisspug.org> > Subject: Re: [HACKERS] unclear about row-level security USING vs. CHECK > > * Peter Eisentraut (pete...@gmx.net) wrote: > > I see. But it is a bit odd to hide this very fundamental behavior > > somewhere in a paragraph that starts out with something about roles. > > I'm happy to change that. You're right, it should be a paragraph by > itself. > > > There is also a mistake, I believe: DELETE policies also take both a > > CHECK and a USING clause. > > DELETE never adds records and therefore does not take a CHECK clause, > only a USING clause: > > =*# create policy p1 on t1 for delete using (c1 > 5) with check (c1 > 10); > ERROR: WITH CHECK cannot be applied to SELECT or DELETE > > There has been some discussion about changing that, but that would be a > future change and not for 9.5. > > > I still find something about this weird, but I'm not sure what. It's > > not clear to me at what level this USING->CHECK mapping is applied. I > > can write FOR ALL USING and it will be mapped to CHECK for all actions, > > including INSERT, but when I write FOR INSERT USING it complains. Why > > doesn't it do the mapping that case, too? > > INSERT is only adding records and therefore only the CHECK policy > applies: > > =*# create policy p1 on t1 for insert using (c1 > 5) with check (c1 > 10); > ERROR: only WITH CHECK expression allowed for INSERT > > The USING clause is for existing records while the CHECK option is for > new records, which is why DELETE only has a USING clause and INSERT only > has a WITH CHECK clause. ALL allows you to specify clauses for all > commands, which is why it accepts both. The only other case which > allows both is UPDATE, where records are both retrived and added. > > > >> (Btw., what's the meaning of a policy for DELETE?) > > > > > > The DELETE policy controls what records a user is able to delete. > > > > That needs to be documented somewhere. > > This is included in the CREATE POLICY documentation: > > DELETE > > Using DELETE for a policy means that it will apply to DELETE > commands. Only rows which pass this policy will be seen by a DELETE > command. Rows may be visible through a SELECT which are not seen by > a DELETE, as they do not pass the USING expression for the DELETE, > and rows which are not visible through the SELECT policy may be > deleted if they pass the DELETE USING policy. The DELETE policy only > accepts the USING expression as it only ever applies in cases where > records are being extracted from the relation for deletion. > > I'm certainly all for improving the documentation, of course. What > about the above isn't clear regarding what DELETE policies do? Or is > the issue that it wasn't covered in ddl-rowsecurity? Perhaps we should > simply move much of the CREATE POLICY documentation into ddl-rowsecurity > instead, since that's where people seem to be looking for this > information? I think that many people will look first into ddl-rowsecurity to get an understanding what it can do and how it can be used. Detailed information is then in the CREATE POLICY doc. So it could make sense to move parts that contribute to understand the mechanics as a whole from the CREATE POLICY doc to ddl-rowsecurity. As an alternative, when it comes to the characteristics of a specific command, a link to the place in CREATE POLICY doc may be enough. Just no duplicated information. That would be difficult to keep in sync. > * Robert Haas (robertmh...@gmail.com) wrote: > > On Sat, Sep 26, 2015 at 9:46 PM, Peter Eisentraut <pete...@gmx.net> wrote: > > > On 9/23/15 3:41 PM, Stephen Frost wrote: > > > I see. But it is a bit odd to hide this very fundamental behavior > > > somewhere in a paragraph that starts out with something about roles. > > > > > > There is also a mistake, I believe: DELETE policies also take both a > > > CHECK and a USING clause. > > > > > > I still find something about this weird, but I'm not sure what. It's > > > not clear to me at what level this USING->CHECK mapping is applied. I > > > can write FOR ALL USING and it will be mapped to CHECK for all actions, > > > including INSERT, but when I
Re: [HACKERS] unclear about row-level security USING vs. CHECK
Hello Peter
> I'm testing the new row-level security feature. I'm not clear on the
> difference between the USING and CHECK clauses in the CREATE POLICY
> statement.
>
> The documentation says:
>
> """
> A policy grants the ability to SELECT, INSERT, UPDATE, or DELETE rows
> which match the relevant policy expression. Existing table rows are
> checked against the expression specified via USING, while new rows that
> would be created via INSERT or UPDATE are checked against the expression
> specified via WITH CHECK. When a USING expression returns true for a
> given row then that row is visible to the user, while if a false or null
> is returned then the row is not visible. When a WITH CHECK expression
> returns true for a row then that row is added, while if a false or null
> is returned then an error occurs.
> """
>
> So basically, USING filters out what you see, CHECK controls what you
> can write.
Yes, for the command that you specified in the FOR clause. This is quite
important if you need different conditions for different commands, e.g. see all
rows, modify only some.
This may help to better understand how this is meant:
http://www.postgresql.org/message-id/20150711132144.gs12...@tamriel.snowman.net
> But then this doesn't work correctly:
>
> CREATE TABLE test1 (content text, entered_by text);
> ALTER TABLE test1 ENABLE ROW LEVEL SECURITY;
> CREATE POLICY test1_policy ON test1 FOR ALL TO PUBLIC USING (entered_by
> = current_user);
> GRANT ALL ON TABLE test1 TO PUBLIC;
>
> CREATE USER foo1;
> SET SESSION AUTHORIZATION foo1;
> INSERT INTO test1 VALUES ('blah', 'foo2'); -- fails
>
> This is a typical you-can-only-see-your-own-rows setup, which works for
> the reading case, but it evidently also controls writes. So I'm not
> sure what the CHECK clause is supposed to add on top of that.
Since the policy is defined for ALL commands and no WITH CHECK is specified
then the same condition defined in USING takes effect for all commands, i.e.
including INSERT.
>From the docs
>(http://www.postgresql.org/docs/9.5/static/sql-createpolicy.html): "Further,
>for commands which can have both USING and WITH CHECK policies (ALL and
>UPDATE), if no WITH CHECK policy is defined then the USING policy will be used
>for both what rows are visible (normal USING case) and which rows will be
>allowed to be added (WITH CHECK case)."
If you want e.g. to allow users to insert rows without the restriction of being
the current_user in column entered_by then you would need separate policies for
each command. If you define a policy for INSERT, USING does not make sense. In
the thread above there is a similar example to this as well as in the
documentation:
http://www.postgresql.org/docs/9.5/static/ddl-rowsecurity.html
> (Btw., what's the meaning of a policy for DELETE?)
In your example it means that users can delete only the rows where entered_by =
current_user. A WITH CHECK policy does not make sense in this case.
I assume that having USING and WITH CHECK for filtering and controlling added
rows was introduced for use cases where these conditions are not the same, i.e.
to allow for more flexibility. On the spot I don't have an example, but maybe
somebody else can deliver one.
Regards
Charles
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Attach comments to functions' parameters and return value
Hello Jim > -Original Message- > From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers- > ow...@postgresql.org] On Behalf Of Charles Clavadetscher > Sent: Dienstag, 15. September 2015 07:35 > To: Jim Nasby <jim.na...@bluetreble.com>; pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Attach comments to functions' parameters and return > value > > Hello Jim > > On 14/09/2015 19:23, Jim Nasby wrote: > > On 9/14/15 8:59 AM, Charles Clavadetscher wrote: > >> Hello > >> > >> In PostgreSQL it is possible to attach comments to almost everything. > >> This > >> made it possible for us to integrate the wiki that we use for our > >> technical > >> documentation directly with the database using the MediaWiki [1] > >> extensions > >> ExternalData [2] and MagicNoCache [3]. The result is a documentation on > >> tables and related objects (indexes, triggers, etc.) and views that > >> always > >> shows the current state, i.e. any DDL change or any comment attached > >> to an > >> object is shown in the wiki immediately (or on refresh if the change was > >> done after the reader landed on the page). > > > > Neat! I hope you'll open source that. :) > > Thank you for your answer. Sure I will put some information on it and > the source on my website soon and let you know. There is not really much > magic to it, but it can be quite helpful. As promised: http://www.schmiedewerkstatt.ch/wiki/index.php/Database_self-documenting_Wik i Feedback, as usual, is always welcome. Bye Charles -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [DOCS] Missing COMMENT ON POLICY
Hi Stephen > On 15.09.2015, at 17:13, Stephen Frost <sfr...@snowman.net> wrote: > > Charles, > > * Charles Clavadetscher (clavadetsc...@swisspug.org) wrote: >> Yes, that helped a lot! In the attachment now a single patch file >> with all changes. > > I've pushed this fix now. > > Thanks! > > Stephen Thanks, too Charles -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Attach comments to functions' parameters and return value
Hello
In PostgreSQL it is possible to attach comments to almost everything. This
made it possible for us to integrate the wiki that we use for our technical
documentation directly with the database using the MediaWiki [1] extensions
ExternalData [2] and MagicNoCache [3]. The result is a documentation on
tables and related objects (indexes, triggers, etc.) and views that always
shows the current state, i.e. any DDL change or any comment attached to an
object is shown in the wiki immediately (or on refresh if the change was
done after the reader landed on the page).
In order to optimize the query, we wrote a small set of sql functions that
generate wiki markup for the objects queried. The idea behind is that this
is much quicker in PostgreSQL than on a web server hosting MediaWiki,
besides a better control of the privileges for the user retrieving data.
So far we can document in such a way tables and views. I started to create
something similar for functions until I noticed that there is no way to
attach comments on functions' parameters and return value. My first idea was
to add this information in the function description, but this is quite an
ugly solution.
My next workaround is to simulate the behaviour of a COMMENT ON FUNCTION
PARAMETER/RETURNVALUE command inserting comments on these directly in
pg_description. For that I used a convention similar to the one used for
table attributes and defined following pg_description.objsubid:
-1 = return value
0 = comment on the function itself (this already exists)
1..n = comment on parameter at position n
An insert would then look like:
INSERT INTO pg_catalog.pg_description
VALUES ('function_name(param_type_list)'::regprocedure,
'pg_proc'::regclass,
parameter_position,
'Comment');
With a simple function similar to the one used to query column descriptions
(pg_catalog.col_description), it is possible to get the comments.
CREATE OR REPLACE FUNCTION pg_catalog.param_description (objoid OID, posnum
INTEGER)
RETURNS TEXT
STABLE
AS $$
SELECT description FROM pg_catalog.pg_description
WHERE objoid = $1
AND classoid = 'pg_catalog.pg_proc'::pg_catalog.regclass
AND objsubid = $2;
$$ LANGUAGE SQL;
Example:
INSERT INTO pg_catalog.pg_description
VALUES ('public.create_wiki_doc(integer,text[],text[])'::regprocedure,
'pg_proc'::regclass,
-1,
'Returns a set of TEXT with wiki formatted description of tables and
views');
INSERT INTO pg_catalog.pg_description
VALUES ('public.create_wiki_doc(integer,text[],text[])'::regprocedure,
'pg_proc'::regclass,
1,
'Wiki title level for each table documentation. The number of "=" to
put before and after the name of the object');
VALUES ('public.create_wiki_doc(integer,text[],text[])'::regprocedure,
'pg_proc'::regclass,
2,
'An array with the list of schemas to be documented');
Etc.
SELECT
param_description('public.create_wiki_doc(integer,text[],text[])'::regproced
ure,-1);
param_description
---
Returns a set of TEXT with wiki formatted description of tables and views
SELECT
param_description('public.create_wiki_doc(integer,text[],text[])'::regproced
ure,1);
param_description
-
Wiki title level for each table documentation. The number of "=" to put
before and after the name of the object
SELECT
param_description('public.create_wiki_doc(integer,text[],text[])'::regproced
ure,2);
param_description
An array with the list of schemas to be documented
Etc.
As I said this is just a workaround and it is not comfortable to manipulate
catalog tables directly. The much better solution would be to have an
implementation of the sql comment command for parameters and return value of
functions built in the system. So my questions on that topic to the
community:
- Is there a reason why this approach should not be followed (currently as
workaround later as implementation in C)?
- Is somebody already doing implementation work in this area or would be
interested in engaging?
- Is there a general interest for that addition?
- Any good advice, tips, suggestions?
I was not completely inactive. I started looking into the code and I am,
honestly, a bit puzzled (see below). If I were to take up the job, which I
would love, I guess that this could not be before the beginning of November
this year. With some help, however, I may be able to start earlier.
What I could find so far looking at the documentation and the code is that
there are quite a number of files to be touched. The given snippets are just
for illustration:
- src/include/nodes/parsenodes.h : Define object types e.g.
FUNCTION_PARAMETER,
Re: [HACKERS] Attach comments to functions' parameters and return value
Hello Àlvaro On 14/09/2015 20:02, Alvaro Herrera wrote: Jim Nasby wrote: On 9/14/15 8:59 AM, Charles Clavadetscher wrote: To long time PostgreSQL developers this may look straightforward. For the moment I am not even sure if that is correct and if there are other places that would need additions, apart from the obvious display in psql. I suspect that changes to support this should be pretty localized. I suggest you look at other recent patches that have added COMMENT functionality to see what they did. This sequence of commits may be helpful. http://git.postgresql.org/gitweb/?p=postgresql.git;a=history;f=src/test/regress/sql/object_address.sql;hb=HEAD Thank you. From the first impression I think that I was not too far away from a correct procedure ;-) I will take a closer look as soon as I can, but I am confident that this will help. Bye Charles -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Attach comments to functions' parameters and return value
Hello Jim On 14/09/2015 19:23, Jim Nasby wrote: On 9/14/15 8:59 AM, Charles Clavadetscher wrote: Hello In PostgreSQL it is possible to attach comments to almost everything. This made it possible for us to integrate the wiki that we use for our technical documentation directly with the database using the MediaWiki [1] extensions ExternalData [2] and MagicNoCache [3]. The result is a documentation on tables and related objects (indexes, triggers, etc.) and views that always shows the current state, i.e. any DDL change or any comment attached to an object is shown in the wiki immediately (or on refresh if the change was done after the reader landed on the page). Neat! I hope you'll open source that. :) Thank you for your answer. Sure I will put some information on it and the source on my website soon and let you know. There is not really much magic to it, but it can be quite helpful. My next workaround is to simulate the behaviour of a COMMENT ON FUNCTION PARAMETER/RETURNVALUE command inserting comments on these directly in pg_description. For that I used a convention similar to the one used for table attributes and defined following pg_description.objsubid: -1 = return value 0 = comment on the function itself (this already exists) 1..n = comment on parameter at position n At first glance, seems reasonable. - Add function to get the position of the parameter, e.g. LookupFuncNamePos(function_name, param_name) or a function to create the whole ObjectAddress e.g. . Something similar might exist already. TBH, to start with, I would only support position number. You'll have to support that case anyway, and it should be simpler. I agree. Since parameter names are optional, supporting the position for comments definition is mandatory and is probably simpler. To long time PostgreSQL developers this may look straightforward. For the moment I am not even sure if that is correct and if there are other places that would need additions, apart from the obvious display in psql. I suspect that changes to support this should be pretty localized. I suggest you look at other recent patches that have added COMMENT functionality to see what they did. Good idea. As a matter of fact, Àlvaro sent a sequence of commits that relate in part to it. I will have a look to it as soon as I can. BTW, I'm also interested in this but I'm not sure when I'd have time to work on it. Good to know, thank you. As I mention in my original post I should be able to work on that in November this year. If I find some time I may start things earlier. Let's keep in touch over this list. Before any coding is done there should be an agreement on the syntax to be used in the statement and the way the information is stored. About the latter I think with the -1,0,1..n solution we are on a good track. For what's concerning the syntax I suggest the following. COMMENT ON FUNCTION function_name ( [ [ argmode ] [ argname ] argtype [, ...] ] ) PARAMETER param_position IS 'text'; COMMENT ON FUNCTION function_name ( [ [ argmode ] [ argname ] argtype [, ...] ] ) RETURN VALUE IS 'text'; An alternative to "RETURN VALUE" could be "RETURNS", which would make the statement shorter, but I think this may be confusing. The parameter list of the function is only required to identify the function also in cases it exists with the same name in different flavours. This sticks to the general syntax of the command and should be easy to understand. Your ideas? Thanks Charles -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] [DOCS] Missing COMMENT ON POLICY
Hello Well I gave it a try. I am still not very well aware how the process for suggesting or submitting corrections work, but this is as far as I got. In the attachment is a patch for the missing entry for POLICY in the documentation on COMMENT that I mentioned earlier on pgsql-docs. Hope this helps. Regards Charles -Original Message- From: pgsql-docs-ow...@postgresql.org [mailto:pgsql-docs-ow...@postgresql.org] On Behalf Of Charles Clavadetscher Sent: Sonntag, 13. September 2015 07:36 To: pgsql-d...@postgresql.org Subject: [DOCS] Missing COMMENT ON POLICY Hello Lately I am working intensively with the documentation capabilities of PostgreSQL and I noticed that, although the functionality is available in 9.5 to add a comment to a policy, there is no entry for in the documentation http://www.postgresql.org/docs/9.5/static/sql-comment.html Probably it would look like: COMMENT ON POLICY policy_name ON table_name | Between OPERATOR FAMILY object_name USING index_method | and [ PROCEDURAL ] LANGUAGE object_name | Regards Charles -- Sent via pgsql-docs mailing list (pgsql-d...@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs comment_on_policy.patch Description: application/softgrid-patch -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [DOCS] Missing COMMENT ON POLICY
Stephen On 13/09/2015 15:26, Charles Clavadetscher wrote: Hello Stephen On 13/09/2015 14:49, Stephen Frost wrote: Charles, Just FYI, on these lists, we'd prefer it if you wouldn't top-post. * Charles Clavadetscher (clavadetsc...@swisspug.org) wrote: Yes, of course. I will take care of that and send a new patch. Thanks! Who will then git push it? I'd be happy to take care of it, though any of the committers may pick it up, of course. If there's a concern about the patch being missed or forgotten then it can be added to the commitfest system (here: http://commitfest.postgresql.org). I don't believe there's a risk of that here, but you're welcome to add it if you'd like, of course. Thank you for your feedback. Thank you for working on this! Stephen In the attachement the new patch. I was not able to create one with both commits so I also added the first one. I think that documentation should be as complete as possible, but if you say that there is no risk in missing the update, then I don't see a need to add a line in the commitfest. Thank you also for the hint on top-posting. I was not aware of that. Have a good Sunday. Charles I noticed that the position of the parameter "policy_name" in the description list of parameters was not at the (alphabetically) correct position. I changed that and the result is attached. I think/hope that is now all correct. Thank you and bye Charles correct_order_position_of_parameter.patch Description: application/softgrid-patch -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [DOCS] Missing COMMENT ON POLICY
Hello Stephen Yes, of course. I will take care of that and send a new patch. Who will then git push it? Thank you for your feedback. Bye Charles > -Original Message- > From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers- > ow...@postgresql.org] On Behalf Of Stephen Frost > Sent: Sonntag, 13. September 2015 14:31 > To: Charles Clavadetscher <clavadetsc...@swisspug.org> > Cc: pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] [DOCS] Missing COMMENT ON POLICY > > Charles, > > * Charles Clavadetscher (clavadetsc...@swisspug.org) wrote: > > Well I gave it a try. I am still not very well aware how the process for > > suggesting or submitting corrections work, but this is as far as I got. > > In the attachment is a patch for the missing entry for POLICY in the > > documentation on COMMENT that I mentioned earlier on pgsql-docs. > > Thanks! This looks mostly correct but only goes half-way (not that > there's a lot to this change ;). The 'policy_name' parameter which is > added should also be added to the 'Parameters' list below, and the > description under 'table_name' updated to reflect that it's used for > policies also. > > There should probably be an example added also, since it looks like > there are examples of pretty much all the other COMMENT ON > types. > > Thanks again! > > Stephen -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [DOCS] Missing COMMENT ON POLICY
Hello Stephen On 13/09/2015 14:49, Stephen Frost wrote: Charles, Just FYI, on these lists, we'd prefer it if you wouldn't top-post. * Charles Clavadetscher (clavadetsc...@swisspug.org) wrote: Yes, of course. I will take care of that and send a new patch. Thanks! Who will then git push it? I'd be happy to take care of it, though any of the committers may pick it up, of course. If there's a concern about the patch being missed or forgotten then it can be added to the commitfest system (here: http://commitfest.postgresql.org). I don't believe there's a risk of that here, but you're welcome to add it if you'd like, of course. Thank you for your feedback. Thank you for working on this! Stephen In the attachement the new patch. I was not able to create one with both commits so I also added the first one. I think that documentation should be as complete as possible, but if you say that there is no risk in missing the update, then I don't see a need to add a line in the commitfest. Thank you also for the hint on top-posting. I was not aware of that. Have a good Sunday. Charles comment_on_policy.patch Description: application/softgrid-patch definitions_and_example_for_comment_on_policy.patch Description: application/softgrid-patch -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [DOCS] Missing COMMENT ON POLICY
Hi Stephen
On 13/09/2015 16:56, Stephen Frost wrote:
Charles,
* Charles Clavadetscher (clavadetsc...@swisspug.org) wrote:
I noticed that the position of the parameter "policy_name" in the
description list of parameters was not at the (alphabetically)
correct position. I changed that and the result is attached.
Thanks!
I think/hope that is now all correct.
We generally prefer one complete patch which represents the total set
of changes to a lot of individual little patches which build on each
other.
If you're using git and have these patches on a branch as different
commits, you can do an interactive rebase to squash them all together,
like this:
git rebase -i
That will open an editor and then you can choose the action to take for
each patch. Generally, I'll make the first patch 'reword' and the
rest 'squash'. Saving and exiting the editor will then take you to
another editor session where you'll have an opportunity to reword the
commit message (to incorporate all of the changes).
Once all of that's done, you can use 'git format-patch' to create a file
which includes the commit message and the patch. I generally run it
like so:
git format-patch @{u} --stdout > ~/patches/filename-for-patch.patch
Hopefully that helps.
Yes, that helped a lot! In the attachment now a single patch file with
all changes.
Thank you a lot. BTW, looking forward to the server programming workshop
in Vienna.
Bye
Charles
update_comment_doc_with_policy.patch
Description: application/softgrid-patch
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
