On Thu, Nov 2, 2017 at 9:53 AM, Connor Wolf
wrote:
> As such:
> Will compound queries as I describe above basically require a custom type to
> make it possible? My (admittedly naive) expectation
> is that the eventual query for this index will look something like "SELECT *
> FROM example_table WHE
On 2 November 2017 at 17:06, Robert Haas wrote:
> On Tue, Oct 31, 2017 at 5:14 PM, Simon Riggs wrote:
>> I've proposed a SQL Standard compliant implementation that would do
>> much more than be new syntax over what we already have.
>>
>> So these two claims aren't accurate: "radical difference" a
On 2 November 2017 at 22:59, Nico Williams wrote:
> On Thu, Nov 02, 2017 at 03:25:48PM -0700, Peter Geoghegan wrote:
>> Nico Williams wrote:
>> >A MERGE mapped to a DML like this:
>>
>> This is a bad idea. An implementation like this is not at all
>> maintainable.
>
> Assuming the DELETE issue ca
PMFJI
> We seem to have a few options for PG11
>
> 1. Do nothing, we reject MERGE
>
> 2. Implement MERGE for unique index situations only, attempting to
> avoid errors (Simon OP)
>
> 3. Implement MERGE, but without attempting to avoid concurrent ERRORs
> (Peter)
>
> 4. Implement MERGE, while a
Amit Langote wrote:
> On 2017/09/06 19:14, Amit Langote wrote:
> > On 2017/09/06 18:46, Rushabh Lathia wrote:
> >> Okay, I have marked this as ready for committer.
> >
> > Thanks Ashutosh and Rushabh for rebasing and improving the patch. Looks
> > good to me too.
>
> Patch needed to be rebased a
On Fri, Nov 3, 2017 at 1:05 PM, Simon Riggs wrote:
>> Therefore, if MERGE eventually uses INSERT .. ON CONFLICT
>> UPDATE when a relevant unique index exists and does something else,
>> such as your proposal of taking a strong lock, or Peter's proposal of
>> doing this in a concurrency-oblivious m
On 3 November 2017 at 07:46, Thomas Kellerer wrote:
> PMFJI
>
>> We seem to have a few options for PG11
>>
>> 1. Do nothing, we reject MERGE
>>
>> 2. Implement MERGE for unique index situations only, attempting to
>> avoid errors (Simon OP)
>>
>> 3. Implement MERGE, but without attempting to avoid
Yeah, unfortunately, the way these type of metric trees work, the entire
search procedure is a function of both the target value and the allowed
search distance. The only way I can think of to return ordered results
without just scanning the entire index would be to repeatedly search the
index whil
> Although this error message is not wrong, I think it should be better
> to
> give error message as "invalid input syntax for type int" for "7.a".
> This could be done by delete "return false;" after "while(...)", let
> the following if to decide which to return.
Ah, now I understand. Sorry, I co
Hi,
On 11/02/2017 06:45 PM, Alvaro Herrera wrote:
> Tomas Vondra wrote:
>
>> Unfortunately, I think we still have a problem ... I've been wondering
>> if we end up producing correct indexes, so I've done a simple test.
>
> Here's a proposed patch that should fix this problem (and does, in my
> t
> pg_hba.conf is "host based access [control]" . I'm not sure it's really the
> right place.
I am open to have another configuration file, say routing_list.conf to define
the routing rules, but felt it is easy to extend the hba conf file.
> But we now have a session-intent stuff though. So we co
> What advantages do you see in doing this in the backend over the current
> system where the concerns are separated, i.e. people use connection poolers
> like pgbouncer to do the routing?
IMHO connection pooler is not great for latency sensitive applications. For
small deployments, proxy is an
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Nov 3, 2017 at 1:05 PM, Simon Riggs wrote:
> > We seem to have a few options for PG11
> >
> > 1. Do nothing, we reject MERGE
> >
> > 2. Implement MERGE for unique index situations only, attempting to
> > avoid errors (Simon OP)
> >
> > 3. Impl
* Stephen Frost (sfr...@snowman.net) wrote:
> and we've certainly not spent effort that I've seen to try to actually
> make libpq work when multiple versions of libpq are linked into the same
> running backend.
... errr, same running application, that is, not backend.
Thanks!
Stephen
signature
On Wed, Nov 1, 2017 at 12:07 AM, Tsunakawa, Takayuki
wrote:
> From: Michael Paquier [mailto:michael.paqu...@gmail.com]
>> On Tue, Oct 31, 2017 at 6:59 AM, Tsunakawa, Takayuki
>> wrote:
>> > When CurrentMemoryContext is NULL, the message is logged with
>> ReportEventA(). This is similar to write
Tom Lane wrote:
> Alvaro Herrera writes:
> > Rather than remove the capability, I'd be inclined to make
> > brin_summarize_new_values summarize the final partial range, and have
> > VACUUM not do it. Would that be too inconsistent?
>
> That doesn't really get you out of the problem that this is
On 03.11.2017 00:32, Piotr Stefaniak wrote:
On 2017-02-28 20:08, Oleg Bartunov wrote:
The standard describes SQL/JSON path language, which used by SQL/JSON query
operators to query JSON. It defines path language as string literal. We
implemented the path language as JSONPATH data type, since o
On Tue, Oct 31, 2017 at 3:45 PM, Peter Eisentraut
wrote:
> It has been pointed out to me that the command deparsing in postgres_fdw
> does not support the INSERT OVERRIDING clause that was added in PG10.
> Here is a patch that seems to fix that. I don't know much about this,
> whether anything el
On Fri, Nov 3, 2017 at 11:29 AM, Nikita Glukhov wrote:
> By standard only string literals can be used in JSON path specifications.
> But of course it is possible to allow to use variable jsonpath expressions
> in
> SQL/JSON functions.
>
> Attached patch implements this feature for JSON query funct
On Fri, Nov 3, 2017 at 1:42 PM, Alvaro Herrera wrote:
> Amit Langote wrote:
>> On 2017/09/06 19:14, Amit Langote wrote:
>> > On 2017/09/06 18:46, Rushabh Lathia wrote:
>> >> Okay, I have marked this as ready for committer.
>> >
>> > Thanks Ashutosh and Rushabh for rebasing and improving the patch.
On Mon, Oct 16, 2017 at 10:08 PM, Andres Freund wrote:
> On 2017-10-16 16:59:59 -0400, Peter Eisentraut wrote:
>> On 9/20/17 04:32, Andres Freund wrote:
>> > Here's what I roughly was thinking of. I don't quite like the name, and
>> > the way the version is specified for libpq (basically just the
On Fri, Nov 3, 2017 at 12:07 PM, Michael Paquier
wrote:
> The patch sent previously does not directly apply on HEAD, and as far
> as I can see the last patch set published on
> https://www.postgresql.org/message-id/2361ae4a-66b1-c6c5-ea6a-84851a1c0...@postgrespro.ru
> has rotten. Could you send a
Ashutosh Bapat wrote:
> On Fri, Nov 3, 2017 at 1:42 PM, Alvaro Herrera
> wrote:
> > I think adding "is partitioned" at end of line isn't good; looks like a
> > phrase but isn't translatable. Maybe add keyword PARTITIONED instead?
>
> In that case may be we should separate bounds and "PARTITION
Some thoughts on this.
On Thu, Nov 2, 2017 at 4:48 PM, Tom Lane wrote:
> Nico Williams writes:
> > With access controls, GUCs could become schema variables, and settings
> > from postgresql.conf could move into the database itself (which I think
> > would be nice).
>
> People re-propose some va
Hi hackers,
1. If you set up a pg_hba.conf with a URL that lacks a base DN or
hostname, hba.c will segfault on startup when it tries to pstrdup a
null pointer. Examples: ldapurl="ldap://localhost"; and
ldapurl="ldap://";.
2. If we fail to bind but have no binddn configured, we'll pass NULL
to
On Mon, Oct 30, 2017 at 10:07 AM, Robert Haas wrote:
> On Mon, Oct 30, 2017 at 9:00 AM, Amit Kapila wrote:
>> Now that the PARAM_EXTERN issue is fixed, I have rebased this patch.
>> This patch had been switched to Ready For Committer in last CF, then
>> Robert had comments which I have addressed,
Hi hackers,
I've run into a few requests for $SUBJECT in the field. I understand
that this is a bit controversial: LDAP + StartTLS (what we already
support) is better than LDAPS because it's a proper standard, and LDAP
auth in general is not as good as some other authentication methods
that we sh
Alvaro Herrera wrote:
> Maybe a solution is to call RelationGetNumberOfBlocks() after the
> placeholder tuple has been inserted, for the case where we would be
> scanning past end of relation; passing InvalidBlockNumber as stop point
> would indicate to do things that way. I'll try with that appr
On Thu, Nov 2, 2017 at 11:36 PM, Fabrízio de Royes Mello
wrote:
> On Thu, Nov 2, 2017 at 5:42 AM, Aleksandr Parfenov
> wrote:
>> Unfortunately, patches 0001 and 0002 don't apply to current master.
>>
>> The new status of this patch is: Waiting on Author
>
> Thanks for your review. Rebased version
README file in patch 0003 is a copy of README from test_pg_dump module
without any changes.
--
Aleksandr Parfenov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscriptio
On Fri, Nov 3, 2017 at 11:43 AM, Aleksandr Parfenov <
a.parfe...@postgrespro.ru> wrote:
>
> README file in patch 0003 is a copy of README from test_pg_dump module
> without any changes.
>
Thanks, I'll fix it.
Regards,
--
Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQL
>> Timbira: http://
On Fri, Nov 3, 2017 at 11:19 AM, Michael Paquier
wrote:
>
> /*
> + * Setup handler to session end hook
> + */
> +if (IsUnderPostmaster)
> +on_proc_exit(do_session_end_hook, 0);
> I think that it would be better to place that in ShutdownPostgres.
> This way it is possible t
Alvaro Herrera writes:
> Alvaro Herrera wrote:
>> Maybe a solution is to call RelationGetNumberOfBlocks() after the
>> placeholder tuple has been inserted, for the case where we would be
>> scanning past end of relation; passing InvalidBlockNumber as stop point
>> would indicate to do things that
On 3 November 2017 at 08:26, Robert Haas wrote:
> On Fri, Nov 3, 2017 at 1:05 PM, Simon Riggs wrote:
>>> Therefore, if MERGE eventually uses INSERT .. ON CONFLICT
>>> UPDATE when a relevant unique index exists and does something else,
>>> such as your proposal of taking a strong lock, or Peter's
Tom Lane wrote:
> Alvaro Herrera writes:
>
> > Yeah, I think this approach results in better code. The attached patch
> > implements that, and it passes the test for me (incl. calling
> > brin_summarize_new_values concurrently with vacuum, when running the
> > insert; the former does include the
Alvaro Herrera writes:
> Tom Lane wrote:
>> Do we still need the complication in brinsummarize to discriminate
>> against the last partial range? Now that the lock consideration
>> is gone, I think that might be a wart.
> In the case of VACUUM, it's not desirable to create a summarization for
>
On Thu, Nov 2, 2017 at 11:46 PM, Tom Lane wrote:
> Sokolov Yura writes:
>> [ 0001-Improve-compactify_tuples.patch, v5 or thereabouts ]
>
> I started to review this patch. I spent a fair amount of time on
> beautifying the code, because I found it rather ugly and drastically
> undercommented. On
On 2017-11-02 06:05:51 -0700, Andres Freund wrote:
> Hi,
>
> On 2017-11-02 13:49:47 +0100, Alvaro Herrera wrote:
> > Andres Freund wrote:
> > > I think the problem is on the pruning, rather than the freezing side. We
> > > can't freeze a tuple if it has an alive predecessor - rather than
> > > wea
Hi,
thanks for checking.
On 02/11/17 10:00, Robert Haas wrote:
> On Wed, Nov 1, 2017 at 8:19 PM, Petr Jelinek
> wrote:
>> sorry for the delay but I didn't have much time in past weeks to follow
>> this thread.
>
> +TimestampTz now = GetCurrentTimestamp();
> +
> /* output previously gat
Antonin Houska wrote:
> This is another version of the patch.
> shard.tgz demonstrates the typical postgres_fdw use case. One query shows base
> scans of base relation's partitions being pushed to shard nodes, the other
> pushes down a join and performs aggregation of the join result on the remo
On 11/2/17 22:07, David Fetter wrote:
> postgres.xml: $(srcdir)/postgres.sgml $(ALLSGML)
> - $(OSX) $(SPFLAGS) $(SGMLINCLUDE) -x lower $< >$@.tmp
> - $(call mangle-xml,book)
> + $(OSX) $(SPFLAGS) $(SGMLINCLUDE) -x lower $< | $(call mangle-xml,book)
The reason why it's not done that wa
On Fri, Nov 03, 2017 at 11:34:18AM -0400, Peter Eisentraut wrote:
> On 11/2/17 22:07, David Fetter wrote:
> > postgres.xml: $(srcdir)/postgres.sgml $(ALLSGML)
> > - $(OSX) $(SPFLAGS) $(SGMLINCLUDE) -x lower $< >$@.tmp
> > - $(call mangle-xml,book)
> > + $(OSX) $(SPFLAGS) $(SGMLINCLUDE) -x lo
Hi,
On 02/09/17 21:08, David Steele wrote:
> Hackers,
>
> The cache in pg_internal.init was reused in days of yore but has been
> rebuilt on postmaster startup since v8.1. It appears there is no reason
> for this file to be backed up.
>
Makes sense.
> I also moved the RELCACHE_INIT_FILENAME c
Tom Lane wrote:
> Alvaro Herrera writes:
> > Tom Lane wrote:
> >> Do we still need the complication in brinsummarize to discriminate
> >> against the last partial range? Now that the lock consideration
> >> is gone, I think that might be a wart.
>
> > In the case of VACUUM, it's not desirable to
On 10/26/17 05:20, Petr Jelinek wrote:
> I found bug in logical replication where extra (nullable) columns on
> subscriber will be reset to NULL value when update comes from provider.
>
> The issue is apparently that we /points finger at himself/ forgot to
> check specifically for columns that are
Simon Riggs wrote:
The *only* behavioural difference I have proposed would be the *lack*
of an ERROR in (some) concurrent cases.
I think that's a big difference. Error vs. non-error is a big deal by
itself;
Are you saying avoiding an ERROR is a bad or good thing?
Are you really asking Rob
On 10/31/17 10:56, Tom Lane wrote:
>> Some functions have a strtol()-like behavior
>> where they take in a const char * and return a pointer into that as
>> another argument. In those cases, I added a cast or two.
> ... but I'm not sure that it's an improvement in cases where you have to
> cast aw
On 11/2/17 16:54, Nico Williams wrote:
> Replacing condeferred and condeferrable with a char columns also
> occurred to me, and though I assume backwards-incompatible changes to
> pg_catalog tables are fair game, I assumed everyone would prefer
> avoiding such changes where possible.
I don't think
On 11/2/17 19:52, Stephen Frost wrote:
> Uh, libpq doesn't actually have symbol versioning, at least not on the
> installed Ubuntu packages for PG10, as shown by objdump -T :
You're right, I was dreaming. But in any case, he would need symbol
versioning of libssl.
--
Peter Eisentraut
On 11/1/17 06:23, Pavel Stehule wrote:
> We need to think about how the \timing option should work in such
> scenarios. Right now it does
> Has the total time sense in this case?
>
> should not be total time related to any fetched result?
The \timing option in psql measures from the ti
On 11/1/17 22:40, Robert Haas wrote:
> That seems like it is at least arguably a wire protocol break. Today,
> if you send a string containing only one command, you will only get
> one answer.
The wire protocol already supports this. And the wire protocol doesn't
really know about statements, on
Peter Eisentraut writes:
> On 10/31/17 10:56, Tom Lane wrote:
>>> Some functions have a strtol()-like behavior
>>> where they take in a const char * and return a pointer into that as
>>> another argument. In those cases, I added a cast or two.
>> ... but I'm not sure that it's an improvement in
On 11/2/17 16:40, Daniel Verite wrote:
> But instead of having procedures not return anything,
> couldn't they return whatever resultset(s) they want to
> ("no resultset" being just a particular case of "anything"),
> so that we could leave out cursors and simply write:
We could in general design
On Fri, Nov 03, 2017 at 01:41:45PM -0400, Peter Eisentraut wrote:
> On 11/2/17 16:54, Nico Williams wrote:
> > Replacing condeferred and condeferrable with a char columns also
> > occurred to me, and though I assume backwards-incompatible changes to
> > pg_catalog tables are fair game, I assumed ev
>From a little experimenting in 9.5, it seems that a referential
integrity trigger is executed with the identity of the referencED
table's owner, but I have not been able to find this covered in
the docs. Is this a documentation oversight, or is it explained
somewhere I didn't look (or may have ski
On Fri, Nov 03, 2017 at 02:09:00PM -0400, Chapman Flack wrote:
> From a little experimenting in 9.5, it seems that a referential
> integrity trigger is executed with the identity of the referencED
> table's owner, but I have not been able to find this covered in
> the docs. Is this a documentation
Chapman Flack writes:
> From a little experimenting in 9.5, it seems that a referential
> integrity trigger is executed with the identity of the referencED
> table's owner, but I have not been able to find this covered in
> the docs. Is this a documentation oversight, or is it explained
> somewher
> Robert Haas writes:
> > We could do that, but the motivation for the current system was to
> > avoid leaking memory in a long-lived context.
Yeah, my approach here is to use a CATCH block that deletes the memory
context just created, thus avoiding a long-lived leak.
Tom Lane wrote:
> Another
Thomas Munro wrote:
> Hi hackers,
>
> src/backend/utils/mb/wchar.c contains a ~16 year old wcwidth
> implementation that originally arrived in commit df4cba68, but the
> upstream code[1] apparently continued evolving and there have been
> more Unicode revisions since. It probably doesn't matter m
Thomas Munro wrote:
> Hi hackers,
>
> src/backend/utils/mb/wchar.c contains a ~16 year old wcwidth
> implementation that originally arrived in commit df4cba68, but the
> upstream code[1] apparently continued evolving and there have been
> more Unicode revisions since.
I think we should update it
Alvaro Herrera writes:
> Tom Lane wrote:
>> It might work to build the new key in a context that's initially a
>> child of CurrentMemoryContext, then reparent it to be a child of
>> CacheMemoryContext when done.
> That's another way (than the PG_TRY block), but I think it's more
> complicated wi
Claudio Freire writes:
> On Thu, Nov 2, 2017 at 11:46 PM, Tom Lane wrote:
>> BTW, the originally given test case shows no measurable improvement
>> on my box.
> I did manage to reproduce the original test and got a consistent improvement.
It occurred to me that I could force the issue by hackin
Andres Freund wrote:
Here's that patch. I've stared at this some, and Robert did too. Robert
mentioned that the commit message might need some polish and I'm not
100% sure about the error message texts yet.
The commit message should probably say that the bug involves the
resurrection of previ
Alvaro Herrera writes:
> Thomas Munro wrote:
>> src/backend/utils/mb/wchar.c contains a ~16 year old wcwidth
>> implementation that originally arrived in commit df4cba68, but the
>> upstream code[1] apparently continued evolving and there have been
>> more Unicode revisions since.
> I think we sh
Peter Geoghegan wrote:
> Andres Freund wrote:
> > Staring at the vacuumlazy hunk I think I might have found a related bug:
> > heap_update_tuple() just copies the old xmax to the new tuple's xmax if
> > a multixact and still running. It does so without verifying liveliness
> > of members. Isn't
Alvaro Herrera wrote:
> I think your argument is sensible for some uses (where people run manual
> VACUUM after loading data) but not others (where people just use manual
> VACUUM in place of autovacuuming -- because they don't trust autovac, or
> the schedule isn't convenient, or whatever other r
On Sat, Nov 4, 2017 at 2:05 AM, Thomas Munro
wrote:
> That
> said, I've only tested the attached lightly on FreeBSD + OpenLDAP and
> don't know if it'll work elsewhere.
Oops, that version's TAP test was a little too dependent on my
system's ldap.conf file. Here's a version that sets the LDAPCONF
Hi Alvaro,
With this v3 patch (assuming this is the one you just committed
as ec42a1dcb30de235b252f6d4) am now getting make check failures.
brin_summarize_range is returning unexpected values.
CentOS6,
PostgreSQL 11devel on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.4.7
20120313 (Red Hat 4.4.7
Alvaro Herrera wrote:
He means that the tuple that heap_update moves to page 1 (which will no
longer be processed by vacuum) will contain a multixact that's older
than relminmxid -- because it is copied unchanged by heap_update instead
of properly checking against age limit.
I see. The problem
Michael Paquier writes:
> On Fri, Nov 3, 2017 at 1:10 AM, Amit Kapila wrote:
>> On Fri, Nov 3, 2017 at 2:54 AM, Tom Lane wrote:
>>> I've marked the CF entry closed. However, I'm not sure if we're quite
>>> done with this thread. Weren't we going to adjust nbtree and hash to
>>> be more aggress
On November 4, 2017 1:22:04 AM GMT+05:30, Alvaro Herrera
wrote:
>Peter Geoghegan wrote:
>> Andres Freund wrote:
>
>> > Staring at the vacuumlazy hunk I think I might have found a related
>bug:
>> > heap_update_tuple() just copies the old xmax to the new tuple's
>xmax if
>> > a multixact and st
Jeff Janes writes:
> With this v3 patch (assuming this is the one you just committed
> as ec42a1dcb30de235b252f6d4) am now getting make check failures.
There's a followup commit already :-(
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgre
I wrote:
> Have not looked at the 0002 patch yet.
I looked at that one, and it seems to be a potential win with no
downside, so pushed. (I tweaked it slightly to avoid an unnecessary
conflict with the test patch I posted earlier.)
regards, tom lane
--
Sent via pgsql-ha
On Fri, Nov 3, 2017 at 1:34 PM, Tom Lane wrote:
> Jeff Janes writes:
> > With this v3 patch (assuming this is the one you just committed
> > as ec42a1dcb30de235b252f6d4) am now getting make check failures.
>
> There's a followup commit already :-(
>
> regards, tom lane
>
On Thu, Nov 2, 2017 at 5:56 AM, Robert Haas wrote:
> On Tue, Oct 31, 2017 at 2:47 PM, Alexander Korotkov
> wrote:
> > However, from user prospective of view, current behavior of
> > hot_standby_feedback is just broken, because it both increases bloat and
> > doesn't guarantee that read-only quer
On Wed, Nov 1, 2017 at 5:55 AM, Masahiko Sawada
wrote:
> On Tue, Oct 31, 2017 at 6:17 PM, Alexander Korotkov
> wrote:
> > On Tue, Oct 31, 2017 at 5:16 AM, Masahiko Sawada
> > wrote:
> >>
> >> On Mon, Oct 30, 2017 at 10:16 PM, Robert Haas
> >> wrote:
> >> > On Tue, Oct 24, 2017 at 1:26 PM, Ivan
On Fri, Nov 3, 2017 at 12:37 PM, Connor Wolf <
conn...@imaginaryindustries.com> wrote:
> EDIT: That's actually exactly how the example I'm working off of works.
> DERP. The SQL is
>
> CREATE TYPE vptree_area AS
> (
> center _int4,
> distance float8
> );
>
> CREATE OR REPLACE FUNCTION vptre
Just clarifying myself a little, since I made a dumb error partway through.
On Thu, Nov 2, 2017 at 10:09 AM, Paul Ramsey
wrote:
> I'm working on a custom aggregate, that generates a serialized data
> format. The preparation of the geometry before being formatted is pretty
> intense, so it is pro
Paul Ramsey writes:
>> Whether I get a parallel aggregate seems entirely determined by the number
>> of rows, not the cost of preparing those rows.
> This is true, as far as I can tell and unfortunate. Feeding tables with
> 100ks of rows, I get parallel plans, feeding 10ks of rows, never do, no
>
On Fri, Nov 3, 2017 at 4:30 PM, Tom Lane wrote:
> Claudio Freire writes:
>> On Thu, Nov 2, 2017 at 11:46 PM, Tom Lane wrote:
>>> BTW, the originally given test case shows no measurable improvement
>>> on my box.
>
>> I did manage to reproduce the original test and got a consistent improvement.
>
On Fri, Nov 3, 2017 at 4:04 PM, Petr Jelinek
wrote:
> Not specific problem to this patch, but I wonder if it should be made
> more clear that those files (there are couple above of what you added)
> are skipped no matter which directory they reside in.
Agreed, it is a good idea to tell in the doc
On Fri, Nov 3, 2017 at 1:55 PM, Fabrízio de Royes Mello
wrote:
>> Passing the database name and user name does not look much useful to
>> me. You can have access to this data already with CurrentUserId and
>> MyDatabaseId.
>
> This way we don't need to convert oid to names inside hook code.
Well,
82 matches
Mail list logo
