Re: [HACKERS] Logical replication and multimaster
On Tue, 15 Dec 2015 21:48:52 -0600 Jim Nasby wrote: > On 12/13/15 7:37 AM, David Fetter wrote: > > As I understand it, pushing these into a library has been proposed but > > not rejected. That it hasn't happened yet is mostly about the lack of > > tuits (the round ones) to rewrite the functionality as libraries and > > refactor pg_dump/pg_restore to use only calls to same. As usual, it's > > less about writing the code and more about the enormous amount of > > testing any such a refactor would entail. > > My understanding as well. IIRC Jon Erdman brought this question up a > couple years ago and the response was "It'd probably be accepted, it's > just that no one has done the work." To be clear, if I understand what you are referring to, my name pops up in this discussion because in Amsterdam around the time that FDWs were originally launched, I had a "brilliant" idea that a great candidate for an FDW would be one that could read from a custom dump (-Fc) file and expose it as though it contained regular tables, so you could restore one erroneously deleted row from a 2TB dump without loading the whole thing, or the whole table in question. On the face of it this seemed relatively simple since a custom dump has a TOC and all the requisite goodies to make this doable, plus the code exists to interpret that (for restoring just one table out of a dump file) and all that was needed was the "glue" to hook it into FDW. Initially the reaction (from Magnus if I'm not mistaken) was "that's stupid, who would want that", but later Dave Page was wholly on board with it. At the next pgcon I spoke up on the same subject at the end of a talk about FDWs where Tom was in attendance, and all agreed my idea had merit...however, unexpectedly they (including Tom) agreed that trying to turn that part of our command line functionality into a library (the proper solution) was more effort than it was worth, and that if I wanted to try it I should just cut and paste the relevant code out of pg_dump and into my FDW, rather than trying to refactor and share said code in a .so. [I was *VERY* surprised by this!] No one said it couldn't be done, but even the "wise men on the mount" conceded that it was such a huge undertaking that it was not worth the effort, and duplicating and subsequently maintaining said duplicated code was the better part of valor. > > I believe that refactoring much of pg_dump's functionality for the > > current version of the server into SQL-accessible functions and making > > pg_dump use only those functions is achievable with available > > resources. > > > > Such a refactor need not be all-or-nothing. For example, the > > dependency resolution stuff is a first step that appears to be worth > > doing by itself even if the effort then pauses, possibly for some > > time. > > If someone wanted to spend time on this, I suspect it'd be worth looking > at how bad some of the backward compatibility issues would be if done in > the server. Maybe they wouldn't be that bad. I suspect the audience for > this code would be much larger if it was in the server as opposed to a C > library. > -- > Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX > Experts in Analytics, Data Architecture and PostgreSQL > Data in Trouble? Get it in Treble! http://BlueTreble.com -- Jon Erdman (aka StuckMojo) PostgreSQL Zealot pgpfBipAAobAu.pgp Description: PGP signature
[HACKERS] Fw: [GENERAL] PLV8 and JS exports / referencing
Got radio silence on this question in -general, and upon reflection I think it
might be a -hacker level question. I'm not sure who actually implemented PLV8,
but I think it might take someone at or near that level to answer.
If not, sorry for the noise. Thanks!
If anyone wants to try to reproduce it, replace the snipped out bits using the
contents of mustache.js from http://github.com/janl/mustache.js and then fiddle
with my "return" line at the bottom to try to reference any function that's
defined in that above snipped portion (such as .render()). Here's a sample sql
call to the full defined pg function, that does work with my hacked up one that
removes the factory:
SELECT mustache('
CREATE TABLE {{{ table_name }}} (
{{{ table_name }}}_id SERIAL PRIMARY KEY
{{ #cols }}
, {{{ def }}}
{{ /cols }}
);'
, '{
"table_name": "my_table"
, "cols": [
{ "def": "t text" }
, { "def": "i int" }
]
}'
);
--
Jon Erdman (aka StuckMojo)
PostgreSQL Zealot
Begin forwarded message:
Date: Wed, 5 Nov 2014 17:01:29 -0600
From: Jon Erdman
To: pgsql-gene...@postgresql.org
Subject: [GENERAL] PLV8 and JS exports / referencing
So, I was trying to use mustache.js in PG by defining a V8 function that
imports it. Older versions worked fine, but in newer versions they use a class
factory and I can't figure out how to reference the mustache stuff that it
creates. Apparently I need to know how our V8 implementation does exports.
Here's the top of mustache.js with the class factory, and my attempted
reference at the bottom (the return which gives me undefined reference). I
tried various invocations and couldn't quite get it. I ended up hacking it up
to remove the factory and change it to explicitly declare a variable to make it
work, but I'd like to avoid that if possible.
If anyone wants to try to reproduce it, replace the snipped out bits using the
contents of mustache.js from http://github.com/janl/mustache.js
CREATE OR REPLACE FUNCTION mustache(template text, view json)
RETURNS TEXT
LANGUAGE plv8
IMMUTABLE
STRICT
AS $$
(function (global, factory) {
if (typeof exports === "object" && exports) {
factory(exports); // CommonJS
} else if (typeof define === "function" && define.amd) {
define(['exports'], factory); // AMD
} else {
factory(global.Mustache = {}); //
Re: [HACKERS] My first patch! (to \df output)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Done. Attached.
- --
Jon T Erdman (aka StuckMojo)
PostgreSQL Zealot
On 01/22/2013 11:17 PM, Phil Sorber wrote:
> On Wed, Jan 23, 2013 at 12:10 AM, Jon Erdman
> wrote:
>
> Updated the patch in commitfest with the doc change, and added a
> comment to explain the whitespace change (it was to clean up the
> sql indentation). I've also attached the new patch here for
> reference.
>
>> Docs looks good. Spaces gone.
>
>> Still need to replace 'definer' and 'invoker' with %s and add
>> the corresponding gettext_noop() calls I think.
>
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with undefined - http://www.enigmail.net/
iEYEARECAAYFAlD/dcoACgkQRAk1+p0GhSEKHQCZAW8UNqSjYxBgBvt2nuffrkrV
+9AAn1hChpY5Jg8G8T3XmlIb+3VUSEQ2
=3cFD
-END PGP SIGNATURE-
diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml
new file mode 100644
index c41593c..0eb6b63
*** a/doc/src/sgml/ref/psql-ref.sgml
--- b/doc/src/sgml/ref/psql-ref.sgml
*** testdb=>
*** 1188,1194
class="parameter">pattern is specified, only
functions whose names match the pattern are shown. If the
form \df+ is used, additional information
! about each function, including volatility, language, source
code and description, is shown. By default, only user-created
objects are shown; supply a pattern or the S
modifier to include system objects.
--- 1188,1194
class="parameter">pattern is specified, only
functions whose names match the pattern are shown. If the
form \df+ is used, additional information
! about each function, including security, volatility, language, source
code and description, is shown. By default, only user-created
objects are shown; supply a pattern or the S
modifier to include system objects.
diff --git a/src/bin/psql/describe.c b/src/bin/psql/describe.c
new file mode 100644
index 15d02ee..3dadc09
*** a/src/bin/psql/describe.c
--- b/src/bin/psql/describe.c
*** describeFunctions(const char *functypes,
*** 254,260
" WHEN p.proiswindow THEN '%s'\n"
" WHEN p.prorettype = 'pg_catalog.trigger'::pg_catalog.regtype THEN '%s'\n"
" ELSE '%s'\n"
! "END as \"%s\"",
gettext_noop("Result data type"),
gettext_noop("Argument data types"),
/* translator: "agg" is short for "aggregate" */
--- 254,260
" WHEN p.proiswindow THEN '%s'\n"
" WHEN p.prorettype = 'pg_catalog.trigger'::pg_catalog.regtype THEN '%s'\n"
" ELSE '%s'\n"
! " END as \"%s\"",
gettext_noop("Result data type"),
gettext_noop("Argument data types"),
/* translator: "agg" is short for "aggregate" */
*** describeFunctions(const char *functypes,
*** 329,342
if (verbose)
appendPQExpBuffer(&buf,
",\n CASE\n"
" WHEN p.provolatile = 'i' THEN '%s'\n"
" WHEN p.provolatile = 's' THEN '%s'\n"
" WHEN p.provolatile = 'v' THEN '%s'\n"
! "END as \"%s\""
",\n pg_catalog.pg_get_userbyid(p.proowner) as \"%s\",\n"
" l.lanname as \"%s\",\n"
" p.prosrc as \"%s\",\n"
" pg_catalog.obj_description(p.oid, 'pg_proc') as \"%s\"",
gettext_noop("immutable"),
gettext_noop("stable"),
gettext_noop("volatile"),
--- 329,349
if (verbose)
appendPQExpBuffer(&buf,
",\n CASE\n"
+ " WHEN prosecdef THEN '%s'\n"
+ " ELSE '%s'\n"
+ " END AS \"%s\""
+ ",\n CASE\n"
" WHEN p.provolatile = 'i' THEN '%s'\n"
" WHEN p.provolatile = 's' THEN '%s'\n"
" WHEN p.provolatile = 'v' THEN '%s'\n"
! " END as \"%s\""
",\n pg_catalog.pg_get_userbyid(p.proowner) as \"%s\",\n"
" l.lanname as \"%s\",\n"
" p.prosrc as \"%s\",\n"
" pg_catalog.obj_description(p.oid, 'pg_proc') as \"%s\"",
+ gettext_noop("definer"),
+ gettext_noop("invoker"),
+ gettext_noop("Security"),
gettext_noop("immutable"),
gettext_noop("stable"),
gettext_noop("volatile"),
0x9D068521.asc
Description: application/pgp-keys
--
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] My first patch! (to \df output)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Updated the patch in commitfest with the doc change, and added a
comment to explain the whitespace change (it was to clean up the sql
indentation). I've also attached the new patch here for reference.
- --
Jon T Erdman (aka StuckMojo)
PostgreSQL Zealot
On 01/20/2013 08:27 PM, Craig Ringer wrote:
> On 01/19/2013 11:54 PM, Jon Erdman wrote:
>> I did realize that since I moved it to + the doc should change,
>> but I didn't address that. I'll get on it this weekend.
> Held as waiting on author, then. Please update
> https://commitfest.postgresql.org/action/patch_view?id=1008 when
> you post a new revision.
>
> -- Craig Ringer http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services
>
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with undefined - http://www.enigmail.net/
iEYEARECAAYFAlD/cNYACgkQRAk1+p0GhSGwJQCfa+8SbL9cYHZkqfmlRlgqcXf9
qD4AnjSZwSXQmOMK8thSs6CdiDxQkJCJ
=H+km
-END PGP SIGNATURE-
diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml
new file mode 100644
index c41593c..0eb6b63
*** a/doc/src/sgml/ref/psql-ref.sgml
--- b/doc/src/sgml/ref/psql-ref.sgml
*** testdb=>
*** 1188,1194
class="parameter">pattern is specified, only
functions whose names match the pattern are shown. If the
form \df+ is used, additional information
! about each function, including volatility, language, source
code and description, is shown. By default, only user-created
objects are shown; supply a pattern or the S
modifier to include system objects.
--- 1188,1194
class="parameter">pattern is specified, only
functions whose names match the pattern are shown. If the
form \df+ is used, additional information
! about each function, including security, volatility, language, source
code and description, is shown. By default, only user-created
objects are shown; supply a pattern or the S
modifier to include system objects.
diff --git a/src/bin/psql/describe.c b/src/bin/psql/describe.c
new file mode 100644
index 15d02ee..5e5cefe
*** a/src/bin/psql/describe.c
--- b/src/bin/psql/describe.c
*** describeFunctions(const char *functypes,
*** 254,260
" WHEN p.proiswindow THEN '%s'\n"
" WHEN p.prorettype = 'pg_catalog.trigger'::pg_catalog.regtype THEN '%s'\n"
" ELSE '%s'\n"
! "END as \"%s\"",
gettext_noop("Result data type"),
gettext_noop("Argument data types"),
/* translator: "agg" is short for "aggregate" */
--- 254,260
" WHEN p.proiswindow THEN '%s'\n"
" WHEN p.prorettype = 'pg_catalog.trigger'::pg_catalog.regtype THEN '%s'\n"
" ELSE '%s'\n"
! " END as \"%s\"",
gettext_noop("Result data type"),
gettext_noop("Argument data types"),
/* translator: "agg" is short for "aggregate" */
*** describeFunctions(const char *functypes,
*** 329,342
if (verbose)
appendPQExpBuffer(&buf,
",\n CASE\n"
" WHEN p.provolatile = 'i' THEN '%s'\n"
" WHEN p.provolatile = 's' THEN '%s'\n"
" WHEN p.provolatile = 'v' THEN '%s'\n"
! "END as \"%s\""
",\n pg_catalog.pg_get_userbyid(p.proowner) as \"%s\",\n"
" l.lanname as \"%s\",\n"
" p.prosrc as \"%s\",\n"
" pg_catalog.obj_description(p.oid, 'pg_proc') as \"%s\"",
gettext_noop("immutable"),
gettext_noop("stable"),
gettext_noop("volatile"),
--- 329,347
if (verbose)
appendPQExpBuffer(&buf,
",\n CASE\n"
+ " WHEN prosecdef THEN 'definer'\n"
+ " ELSE 'invoker'\n"
+ " END AS \"%s\""
+ ",\n CASE\n"
" WHEN p.provolatile = 'i' THEN '%s'\n"
" WHEN p.provolatile = 's' THEN '%s'\n"
" WHEN p.provolatile = 'v' THEN '%s'\n"
! " END as \"%s\""
",\n pg_catalog.pg_get_userbyid(p.proowner) as \"%s\",\n"
" l.lanname as \"%s\",\n"
" p.prosrc as \"%s\",\n"
" pg_catalog.obj_description(p.oid, 'pg_proc') as \"%s\"",
+ gettext_noop("Security"),
gettext_noop("immutable"),
gettext_noop("stable"),
gettext_noop("volatile"),
0x9D068521.asc
Description: application/pgp-keys
--
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] My first patch! (to \df output)
I did realize that since I moved it to + the doc should change, but I didn't address that. I'll get on it this weekend. As far as the column name and displayed values go, they're taken from the CREATE FUNCTION syntax, and were recommended by Magnus, Bruce, and Fetter, who were all sitting next to me day after pgconf.eu Prague. I personally have no strong feelings either way, I just want to be able to see the info without having to directly query pg_proc. Whatever you all agree on is fine by me. -- Jon T Erdman Chief Information Officervoice: (312) 285-6735 Progressive Practice, Inc. j...@progressivepractice.com P.O. Box 17288 www.progressivepractice.com Rochester, NY 14617 On Jan 18, 2013, at 5:51 PM, Phil Sorber wrote: > On Sat, Dec 29, 2012 at 1:56 PM, Stephen Frost wrote: >> * Jon Erdman (postgre...@thewickedtribe.net) wrote: >>> Oops! Here it is in the proper diff format. I didn't have my env set up >>> correctly :( >> >> No biggie, and to get the bike-shedding started, I don't really like the >> column name or the values.. :) I feel like something clearer would be >> "Runs_As" with "caller" or "owner".. Saying "Security" makes me think >> of ACLs more than what user ID the function runs as, to be honest. >> >> Looking at the actual patch itself, it looks like you have some >> unecessary whitespace changes included..? >> >>Thanks! >> >>Stephen > > Stephen, I think Jon's column name and values make a lot of sense. > That being said, I do agree with your point of making it clearer for > the person viewing the output, I just don't know if it would be > confusing when they wanted to change it or were trying to understand > how it related. > > Agree on the extra spaces in the docs. > > Jon, I think you inserted your changes improperly in the docs. The > classifications apply to the type, not to security. > > Also, you need to use the %s place holder and the gettext_noop() call > for your values as well as your column name. > > Compiles and tests ok. Results look as expected. -- 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] My first patch! (to \df output)
Oops! Here it is in the proper diff format. I didn't have my env set up correctly :( describe.patch Description: Binary data -- Jon T Erdman Postgresql Zealot On Nov 9, 2012, at 1:53 PM, Jon Erdman wrote: > On Oct 27, 2012, at 10:45 AM, Pavel Stehule wrote: > >> Hello >> >> 2012/10/27 Jon Erdman : >>> >>> Hello Hackers! >>> >>> So, currently the only way to see if a function is security definer or not >>> is to directly query pg_proc. This is both irritating, and I think perhaps >>> dangerous since security definer functions can be so powerful. I thought >>> that rectifying that would make an excellent first patch, and I was bored >>> today here in Prague since pgconf.eu is now over...so here it is. :) >>> >>> This patch adds a column to the output of \df titled "Security" with values >>> of "definer" or "invoker" based on the boolean secdef column from pg_proc. >>> I've also included a small doc patch to match. This patch is against master >>> from git. Comments welcome! >>> >>> I just realized I didn't address regression tests, so I guess this is not >>> actually complete yet. I should have time for that next week after I get >>> back to the states. >>> >>> I would also like to start discussion about perhaps adding a couple more >>> things to \df+, specifically function execution permissions (which are also >>> exposed nowhere outside the catalog to my knowledge), and maybe search_path >>> since that's related to secdef. Thoughts? >> >> I prefer show this in \dt+ for column "Security" - and for other >> functionality maybe new statement. > > I'm assuming you meant "\df+", and I've changed it accordingly. With this > change there is now nothing to change in the regression tests, so please > consider this my formal and complete submission. > > Is there anything else I need to do to get this considered? > > Oh, in case anyone is interested, here's what the query now looks like and > the new output: > > jerdman=# \df+ public.akeys > * QUERY ** > SELECT n.nspname as "Schema", > p.proname as "Name", > pg_catalog.pg_get_function_result(p.oid) as "Result data type", > pg_catalog.pg_get_function_arguments(p.oid) as "Argument data types", > CASE > WHEN p.proisagg THEN 'agg' > WHEN p.proiswindow THEN 'window' > WHEN p.prorettype = 'pg_catalog.trigger'::pg_catalog.regtype THEN 'trigger' > ELSE 'normal' > END as "Type", > CASE > WHEN prosecdef THEN 'definer' > ELSE 'invoker' > END AS "Security", > CASE > WHEN p.provolatile = 'i' THEN 'immutable' > WHEN p.provolatile = 's' THEN 'stable' > WHEN p.provolatile = 'v' THEN 'volatile' > END as "Volatility", > pg_catalog.pg_get_userbyid(p.proowner) as "Owner", > l.lanname as "Language", > p.prosrc as "Source code", > pg_catalog.obj_description(p.oid, 'pg_proc') as "Description" > FROM pg_catalog.pg_proc p > LEFT JOIN pg_catalog.pg_namespace n ON n.oid = p.pronamespace > LEFT JOIN pg_catalog.pg_language l ON l.oid = p.prolang > WHERE p.proname ~ '^(akeys)$' > AND n.nspname ~ '^(public)$' > ORDER BY 1, 2, 4; > ** > > List of functions > Schema | Name | Result data type | Argument data types | Type | Security | > Volatility | Owner | Language | Source code | Description > +---+--+-++--++-+--+--+- > public | akeys | text[] | hstore | normal | invoker | > immutable | jerdman | c| hstore_akeys | > (1 row) > > -- > Jon T Erdman > Postgresql Zealot > > -- 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] My first patch! (to \df output)
On Oct 27, 2012, at 10:45 AM, Pavel Stehule wrote: > Hello > > 2012/10/27 Jon Erdman : >> >> Hello Hackers! >> >> So, currently the only way to see if a function is security definer or not >> is to directly query pg_proc. This is both irritating, and I think perhaps >> dangerous since security definer functions can be so powerful. I thought >> that rectifying that would make an excellent first patch, and I was bored >> today here in Prague since pgconf.eu is now over...so here it is. :) >> >> This patch adds a column to the output of \df titled "Security" with values >> of "definer" or "invoker" based on the boolean secdef column from pg_proc. >> I've also included a small doc patch to match. This patch is against master >> from git. Comments welcome! >> >> I just realized I didn't address regression tests, so I guess this is not >> actually complete yet. I should have time for that next week after I get >> back to the states. >> >> I would also like to start discussion about perhaps adding a couple more >> things to \df+, specifically function execution permissions (which are also >> exposed nowhere outside the catalog to my knowledge), and maybe search_path >> since that's related to secdef. Thoughts? > > I prefer show this in \dt+ for column "Security" - and for other > functionality maybe new statement. I'm assuming you meant "\df+", and I've changed it accordingly. With this change there is now nothing to change in the regression tests, so please consider this my formal and complete submission. describe.patch Description: Binary data Is there anything else I need to do to get this considered? Oh, in case anyone is interested, here's what the query now looks like and the new output: jerdman=# \df+ public.akeys * QUERY ** SELECT n.nspname as "Schema", p.proname as "Name", pg_catalog.pg_get_function_result(p.oid) as "Result data type", pg_catalog.pg_get_function_arguments(p.oid) as "Argument data types", CASE WHEN p.proisagg THEN 'agg' WHEN p.proiswindow THEN 'window' WHEN p.prorettype = 'pg_catalog.trigger'::pg_catalog.regtype THEN 'trigger' ELSE 'normal' END as "Type", CASE WHEN prosecdef THEN 'definer' ELSE 'invoker' END AS "Security", CASE WHEN p.provolatile = 'i' THEN 'immutable' WHEN p.provolatile = 's' THEN 'stable' WHEN p.provolatile = 'v' THEN 'volatile' END as "Volatility", pg_catalog.pg_get_userbyid(p.proowner) as "Owner", l.lanname as "Language", p.prosrc as "Source code", pg_catalog.obj_description(p.oid, 'pg_proc') as "Description" FROM pg_catalog.pg_proc p LEFT JOIN pg_catalog.pg_namespace n ON n.oid = p.pronamespace LEFT JOIN pg_catalog.pg_language l ON l.oid = p.prolang WHERE p.proname ~ '^(akeys)$' AND n.nspname ~ '^(public)$' ORDER BY 1, 2, 4; ** List of functions Schema | Name | Result data type | Argument data types | Type | Security | Volatility | Owner | Language | Source code | Description +---+--+-++--++-+--+--+- public | akeys | text[] | hstore | normal | invoker | immutable | jerdman | c| hstore_akeys | (1 row) -- Jon T Erdman Postgresql Zealot -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] My first patch! (to \df output)
Hello Hackers! So, currently the only way to see if a function is security definer or not is to directly query pg_proc. This is both irritating, and I think perhaps dangerous since security definer functions can be so powerful. I thought that rectifying that would make an excellent first patch, and I was bored today here in Prague since pgconf.eu is now over...so here it is. :) This patch adds a column to the output of \df titled "Security" with values of "definer" or "invoker" based on the boolean secdef column from pg_proc. I've also included a small doc patch to match. This patch is against master from git. Comments welcome! I just realized I didn't address regression tests, so I guess this is not actually complete yet. I should have time for that next week after I get back to the states. I would also like to start discussion about perhaps adding a couple more things to \df+, specifically function execution permissions (which are also exposed nowhere outside the catalog to my knowledge), and maybe search_path since that's related to secdef. Thoughts? This was actually kind of anti-climactic, since it only took about 5 minutes to make the change and get it working. Didn't really feel the way I expected it to ;) describe.patch Description: Binary data -- Jon T Erdman Postgresql Zealot -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Proposing new logline_prefix escape...
So... Came across a situation today where I would have liked to know the effective role of a query because of a permission error. When I went to add that to the logline_prefix, I realized that right now all we have is %u which gives you the equivalent of session_user...I think it would be useful to have one for current_user, for situations like mine where a function was changing the effective role. Thoughts? Disagreements? Flames? -- Jon T Erdman Chief Information Officer Progressive Practice, Inc. P.O. Box 17288 Rochester, NY 14617 www.progressivepractice.com signature.asc Description: OpenPGP digital signature
[HACKERS] Proposing new logline_prefix escape...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 So... Came across a situation today where I would have liked to know the effective role of a query because of a permission error. When I went to add that to the logline_prefix, I realized that right now all we have is %u which gives you the equivalent of session_user...I think it would be useful to have one for current_user, for situations like mine where a function was changing the effective role. Thoughts? Disagreements? Flames? - -- Jon T Erdman Chief Information Officer Progressive Practice, Inc. P.O. Box 17288 Rochester, NY 14617 www.progressivepractice.com -BEGIN PGP SIGNATURE- iEYEARECAAYFAksXGpUACgkQRAk1+p0GhSG+kQCfej6dcViCC5IR7dgAdps0tZaN UVAAnRQTG+GW/0lMQZt1rFGF9IHAAp6K =0tg4 -END PGP SIGNATURE- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
