Hello,
I'd consider [...]
Don't really see the value of either ...
What I see is [...].
I still don't see the value of it. [...].
Ok. I suggested to consider, you considered and rejected, fine with me!
--
Fabien.
On Tue, Aug 7, 2018 at 4:19 PM, Andrey Lepikhov
wrote:
> Hi,
> I wrote a background worker (hcleaner) to demonstrate application of Retail
> IndexTuple deletion (see patch at attachment).
The patch doesn't seem to have the hcleaner code. Could you share it?
Regards,
--
Masahiko Sawada
NIPPON TE
Hello Marina,
v10-0004-Pgbench-errors-and-serialization-deadlock-retrie.patch
- the main patch for handling client errors and repetition of transactions
with serialization/deadlock failures (see the detailed description in the
file).
Patch applies cleanly.
It allows retrying a script (con
On Tue, Aug 14, 2018 at 06:38:56PM +0300, Alexander Korotkov wrote:
> BTW, I've also revised documentation and regression tests. Patch is attached.
I looked at the patch. It applies without errors.
The document looks good. It compiles.
The code looks good too. It compiles and tests are passed.
(2018/08/15 13:04), Amit Langote wrote:
On 2018/08/15 12:25, Etsuro Fujita wrote:
(2018/08/15 0:51), Robert Haas wrote:
On Mon, Aug 13, 2018 at 12:32 PM, Etsuro Fujita
wrote:
One thing I noticed might be an improvement is to skip
build_joinrel_partition_info if the given joinrel will be to
On 07/08/2018 16:06, Tom Lane wrote:
> In short, yeah, I think we could nuke that. But maybe Peter remembers
> it differently.
It's all obsolete with git clean anyway.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Servi
> On Aug 14, 2018, at 1:30 PM, Andres Freund wrote:
>
> Hi,
>
> On 2018-08-12 08:51:28 +0100, Shay Rojansky wrote:
>> Peter, Tom,
>>
>> Would it be possible for you to review the following two questions? Some
>> assertions have been made in this thread about the new stored procedures
>> (suppo
> "Andrew" == Andrew Gierth writes:
Patch take 2. Changes:
1. Remove cleanup function with retail pfree()s; this was added in
commit ae65ca312 (Aug 2007) to fix an actual memory leak, but obsoleted
by commit ff428cded (Feb 2008); since then, the pfrees were pointless
since all the freed obje
Tatsuro Yamada writes:
> Attached patch gives the following query a semicolon for readability.
>s/SELECT pg_catalog.set_config ('search_path', '', false)/
> SELECT pg_catalog.set_config ('search_path', '', false);/
I'm not exactly convinced that this is worth doing. There are an
awful l
On Wed, Aug 15, 2018 at 7:35 AM, Etsuro Fujita
wrote:
> Thanks for the comments, Robert!
Given the comments from the RMT, and also on general principle, it
seems like we really need to get on with committing something here.
It's my understanding you plan to do that, since it's your patch.
When?
On Thu, Aug 9, 2018 at 11:44 AM, Tom Lane wrote:
> I noticed that, although most error reports during libpq's connection
> setup code append to conn->errorMessage, the ones in fe-auth.c and
> fe-auth-scram.c don't: they're all printfPQExpBuffer() not
> appendPQExpBuffer(). This seems wrong to me.
On Tue, Aug 14, 2018 at 7:28 PM, Tom Lane wrote:
> I'm almost tempted to think that the reasons above make this a
> back-patchable bug fix. Comments?
No objections to changing the behavior. Have you checked whether
there are any noticeable performance consequences?
Back-patching seems a bit ag
On Tue, Aug 14, 2018 at 4:42 PM, Bruce Momjian wrote:
> So you are saying PG functions should lock down their search path at
> function definition time, and use that for all function invocations?
Yes, mostly. I don't think we can just change the existing behavior;
it would break a catastrophic a
On Tue, Aug 14, 2018 at 11:50:24PM +, Nasby, Jim wrote:
> On Aug 14, 2018, at 4:01 PM, Nico Williams wrote:
> >
> > On Tue, Aug 14, 2018 at 03:00:55PM +, Robert Haas wrote:
> >> The more I think about it, the more I think having a way to set a
> >> lexically-scoped search path is probably
Robert Haas writes:
> On Tue, Aug 14, 2018 at 7:28 PM, Tom Lane wrote:
>> I'm almost tempted to think that the reasons above make this a
>> back-patchable bug fix. Comments?
> No objections to changing the behavior. Have you checked whether
> there are any noticeable performance consequences?
Hi,
On 2018-08-15 11:41:46 -0400, Tom Lane wrote:
> BTW, independently of whether to back-patch, it strikes me that what
> we ought to do in HEAD (after applying this) is to just assume we have
> C99-compliant behavior, and rip out the baroque logic in psnprintf
> and appendPQExpBufferVA that trie
Robert Haas writes:
> On Thu, Aug 9, 2018 at 11:44 AM, Tom Lane wrote:
>> So I think we should basically s/printfPQExpBuffer/appendPQExpBuffer/g
>> anywhere those files touch conn->errorMessage, allowing any problems
>> with previous servers to be preserved in the eventually-reported message.
>
On Wed, Aug 15, 2018 at 11:53 AM, Tom Lane wrote:
> Well, I'm actually not proposing to print "maximum detail", and Fabien
> is complaining about that, which makes me think maybe I've hit a happy
> medium ;-). In particular, the proposed patches won't change behavior
> for cases where you just gi
On 2018-Aug-15, Robert Haas wrote:
> On Tue, Aug 14, 2018 at 7:28 PM, Tom Lane wrote:
> > I'm almost tempted to think that the reasons above make this a
> > back-patchable bug fix. Comments?
>
> No objections to changing the behavior. Have you checked whether
> there are any noticeable perform
On Wed, Aug 15, 2018 at 11:52 AM, Andres Freund wrote:
> We could just mandate C99, more generally.
>
> /me goes and hides in a bush.
It's hard to believe that would cost much. Personally, I'd prefer to
continue avoiding // comments and intermingled declarations of
variables and code on grounds
On Tue, Aug 14, 2018 at 5:14 PM, Mark Dilger wrote:
> I think you are interpreting the problem too broadly. This is basically
> just a privilege escalation attack vector.
Hmm. Well, I think you're interpreting the problem too narrowly. :-)
In my view, the problem isn't just that there is a ri
On Tue, Aug 14, 2018 at 10:44 PM, Noah Misch wrote:
> Right. For what it's worth, the example I permuted upthread might look like
> this in a lexical search path world:
>
> -- Always secure, even if schema usage does not conform to
> ddl-schemas-patterns
> -- and function trust is disabled or un
Robert Haas writes:
> On Wed, Aug 15, 2018 at 11:53 AM, Tom Lane wrote:
>> As soon as you have multiple target hosts, though, the current code's
>> behavior is inadequate IMO.
> I'm not entirely convinced; see the example I posted before.
TBH I find your example to be the exact opposite of conv
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2018-08-15 11:41:46 -0400, Tom Lane wrote:
> > BTW, independently of whether to back-patch, it strikes me that what
> > we ought to do in HEAD (after applying this) is to just assume we have
> > C99-compliant behavior, and rip out the bar
Hi,
On 2018-08-15 12:01:28 -0400, Robert Haas wrote:
> On Wed, Aug 15, 2018 at 11:52 AM, Andres Freund wrote:
> > We could just mandate C99, more generally.
> >
> > /me goes and hides in a bush.
>
> It's hard to believe that would cost much.
Yea.
> Personally, I'd prefer to continue avoiding
Robert Haas writes:
> On Wed, Aug 15, 2018 at 11:52 AM, Andres Freund wrote:
>> We could just mandate C99, more generally.
>>
>> /me goes and hides in a bush.
> It's hard to believe that would cost much.
I think we have done that, piece by piece, where it was actually buying us
something. In
On Wed, Aug 15, 2018 at 12:05 PM, Tom Lane wrote:
> TBH I find your example to be the exact opposite of convincing.
> You've cherry-picked a case where the current behavior tells you
> what you need to know and not anything you don't, but very small
> variations on the case make that not hold anym
Robert Haas writes:
> On Wed, Aug 15, 2018 at 12:05 PM, Tom Lane wrote:
>> TBH I find your example to be the exact opposite of convincing.
> That seems like a pretty unlikely use case, though. It seems to me
> that the virtue of the feature is in letting you connect to one of a
> number of host
Alvaro Herrera writes:
> On 2018-Aug-15, Robert Haas wrote:
>> Back-patching seems a bit aggressive to me considering that the danger
>> is hypothetical.
> That was my first thought too, and my preferred path would be to make
> this master-only and only consider a backpatch later if we find some
On Wed, Aug 15, 2018 at 12:46 PM, Tom Lane wrote:
> I think the author(s) of that patch understood
> the problem perfectly well, but were too lazy or cowardly to fix it other
> than in code they were adding.
I think this is an ad hominum attack.
I have explained some factors that are relevant fr
On 2018-Aug-03, Alvaro Herrera wrote:
> On 2018-Aug-03, Kyotaro HORIGUCHI wrote:
>
> > That said, I don't object to reduce the columns. Please find the
> > attached.
>
> Thanks, pushed.
I had failed to push in the 9.4 branch. Done now.
--
Álvaro Herrerahttps://www.2ndQuadrant
On 8/15/18 12:17 PM, Tom Lane wrote:
> Robert Haas writes:
>
>> Personally, I'd prefer to
>> continue avoiding // comments and intermingled declarations of
>> variables and code on grounds of style and readability.
>
> ... which I agree with.
We already have -Wdeclaration-after-statement to pre
I wrote:
> Meh --- the hazards of back-patching seem to me to be more hypothetical
> than the benefits. Still, I seem to be in the minority, so I withdraw
> the proposal to back-patch.
Actually, after digging around a bit, I'm excited about this again.
There are only a couple dozen places in our
David Steele writes:
> On 8/15/18 12:17 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> Personally, I'd prefer to
>>> continue avoiding // comments and intermingled declarations of
>>> variables and code on grounds of style and readability.
>> ... which I agree with.
> We already have -Wdeclarat
On 08/15/2018 12:17 PM, Tom Lane wrote:
Robert Haas writes:
Personally, I'd prefer to
continue avoiding // comments and intermingled declarations of
variables and code on grounds of style and readability.
... which I agree with.
A decade or so ago I would have strongly agreed with you
1. Why do the files holding the spilled transaction data in reorderbuffer.c
have a ".snap" suffix?
2. Those files can get quite large. Would it be reasonable to store them in
another directory (e.g. pg_replslot_tmp) so that they can be placed on
another mount point? It would also simplify the clea
On Wed, Aug 15, 2018 at 11:05:06AM -0400, Robert Haas wrote:
> On Tue, Aug 14, 2018 at 4:42 PM, Bruce Momjian wrote:
> > So you are saying PG functions should lock down their search path at
> > function definition time, and use that for all function invocations?
>
> Yes, mostly. I don't think we
Andrew Dunstan writes:
> On 08/15/2018 12:17 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> Personally, I'd prefer to
>>> continue avoiding // comments and intermingled declarations of
>>> variables and code on grounds of style and readability.
>> ... which I agree with.
> A decade or so ago I
On 08/15/2018 03:18 PM, Tom Lane wrote:
FWIW, the issue I've got with what C99 did is that you can narrow the
*start* of the scope of a local variable easily, but not the *end* of
its scope, which seems to me to be solving at most half of the problem.
To solve the whole problem, you end up ne
On Wed, Aug 15, 2018 at 03:22:10PM -0400, Stephen Frost wrote:
> Greetings,
>
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > Unless there are substantial objections, or nontrivial changes as a result
> > of this round of comments, we anticipate making the CoC official as of
> > July 1 2018.
>
> We
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Unless there are substantial objections, or nontrivial changes as a result
>> of this round of comments, we anticipate making the CoC official as of
>> July 1 2018.
> We seem to be a bit past that timeline... Do we have any update
On 8/15/18 3:18 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 08/15/2018 12:17 PM, Tom Lane wrote:
>>> Robert Haas writes:
Personally, I'd prefer to
continue avoiding // comments and intermingled declarations of
variables and code on grounds of style and readability.
>
>>> ..
David Steele writes:
> On 8/15/18 3:18 PM, Tom Lane wrote:
>> I do dearly miss the ability to easily limit the scope of a loop's
>> control variable to just the loop, eg
>> for (int i = 0; ...) { ... }
>> But AFAIK that's C++ not C99.
> This works in C99 -- and I'm a really big fan.
It does
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Unless there are substantial objections, or nontrivial changes as a result
> of this round of comments, we anticipate making the CoC official as of
> July 1 2018.
We seem to be a bit past that timeline... Do we have any update on when
this will
Hi,
On 2018-08-15 12:04:12 -0700, Jeff Davis wrote:
> 1. Why do the files holding the spilled transaction data in reorderbuffer.c
> have a ".snap" suffix?
I don't remember the genesis of that, sorry. I guess .spill or such
would have been better. Perhaps it was because I initially intended for
t
On 12/08/2018 09:51, Shay Rojansky wrote:
> Would it be possible for you to review the following two questions? Some
> assertions have been made in this thread about the new stored procedures
> (support for dynamic and multiple resultsets) whose compatibility with
> the current PostgreSQL protocol
Hi,
On 2018-08-15 15:57:43 -0400, Tom Lane wrote:
> I'd always thought this was only in C++. This alone might be a sufficient
> reason to drop C89 compiler support ...
It's also IIRC reasonably widely supported from before C99. So, for the
sake of designated initializers, for loop scoping, snpri
On 2018-08-15 14:05:29 -0400, Tom Lane wrote:
> I wrote:
> > Meh --- the hazards of back-patching seem to me to be more hypothetical
> > than the benefits. Still, I seem to be in the minority, so I withdraw
> > the proposal to back-patch.
>
> Actually, after digging around a bit, I'm excited abou
Peter Eisentraut writes:
> On 12/08/2018 09:51, Shay Rojansky wrote:
>> Would it be possible for you to review the following two questions? Some
>> assertions have been made in this thread about the new stored procedures
>> (support for dynamic and multiple resultsets) whose compatibility with
>>
Andres Freund writes:
> On 2018-08-15 15:57:43 -0400, Tom Lane wrote:
>> I'd always thought this was only in C++. This alone might be a sufficient
>> reason to drop C89 compiler support ...
> It's also IIRC reasonably widely supported from before C99. So, for the
> sake of designated initializer
Andres Freund writes:
> On 2018-08-15 14:05:29 -0400, Tom Lane wrote:
>> Still want to argue for no backpatch?
> I'm a bit confused. Why did you just backpatch this ~two hours after
> people objected to the idea? Even if it were during my current work
> hours, I don't even read mail that often i
> On Aug 10, 2018, at 4:39 AM, Peter Eisentraut
> wrote:
>
> On 09/08/2018 20:25, Vik Fearing wrote:
>> On 09/08/18 20:13, Peter Eisentraut wrote:
>>> On 09/08/2018 19:57, hubert depesz lubaczewski wrote:
I just noticed that when I called a procedure that commits and rollbacks
- the x
Hi,
On 2018-08-15 18:13:59 -0400, Tom Lane wrote:
> Experimenting here says that even reasonably modern gcc's won't take
> declarations-inside-for without "--std=c99" or such. No idea about
> other compilers. So we'd have a little bit of work to do on
> configuration before we could open the flo
Andres Freund writes:
> On 2018-08-15 18:13:59 -0400, Tom Lane wrote:
>> Experimenting here says that even reasonably modern gcc's won't take
>> declarations-inside-for without "--std=c99" or such.
> I think autoconf's magic knows about most of that:
> — Macro: AC_PROG_CC_C99
Ah, of course. Wh
Hi,
On 2018-08-15 18:31:10 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2018-08-15 18:13:59 -0400, Tom Lane wrote:
> >> Experimenting here says that even reasonably modern gcc's won't take
> >> declarations-inside-for without "--std=c99" or such.
>
> > I think autoconf's magic knows abo
> Well, no, actually I think it wouldn't. Multiple rowsets coming back
> from a single query is, to my mind anyway, forbidden in the extended query
> mode. Yeah, we could probably get away with it in simple query mode
> (PQexec), but it's very likely to break clients in extended mode, because
> t
On Thu, Aug 16, 2018 at 10:40 AM, Andres Freund wrote:
> Hi,
>
> On 2018-08-15 18:31:10 -0400, Tom Lane wrote:
>> Andres Freund writes:
>> > On 2018-08-15 18:13:59 -0400, Tom Lane wrote:
>> >> Experimenting here says that even reasonably modern gcc's won't take
>> >> declarations-inside-for witho
Thomas Munro writes:
> Really? I am not an MSVC user but I had the impression that their C
> mode (/TC or files named .c) was stuck on C89/C90 as a matter of
> policy, as Herb Sutter explained here (though maybe the situation has
> changed since then):
> https://herbsutter.com/2012/05/03/reader-
Hi,
On 2018-08-16 10:54:01 +1200, Thomas Munro wrote:
> Really? I am not an MSVC user but I had the impression that their C
> mode (/TC or files named .c) was stuck on C89/C90 as a matter of
> policy, as Herb Sutter explained here (though maybe the situation has
> changed since then):
They revis
hi all! I discovered today that the REFRESH MATERIALIZED VIEW
documentation doesn't mention that only the owner (or a superuser) may
actually perform the refresh operation. This patch adds a note to that
effect.
Dian Fay
diff --git a/doc/src/sgml/ref/refresh_materialized_view.sgml b/doc/src/s
On Wed, Aug 15, 2018 at 02:35:56PM -0300, Alvaro Herrera wrote:
> I had failed to push in the 9.4 branch. Done now.
Thanks Alvaro for working on the details. I would not have bothered
much myself as the set of columns was correct in 9.4, but for
consistency's sake that makes sense.
--
Michael
I wrote:
> BTW, independently of whether to back-patch, it strikes me that what
> we ought to do in HEAD (after applying this) is to just assume we have
> C99-compliant behavior, and rip out the baroque logic in psnprintf
> and appendPQExpBufferVA that tries to deal with pre-C99 snprintf.
Here's a
On Thu, Aug 16, 2018 at 11:06 AM, Andres Freund wrote:
> On 2018-08-16 10:54:01 +1200, Thomas Munro wrote:
>> Really? I am not an MSVC user but I had the impression that their C
>> mode (/TC or files named .c) was stuck on C89/C90 as a matter of
>> policy, as Herb Sutter explained here (though ma
On Mon, Aug 13, 2018 at 01:39:06PM -0400, Robert Haas wrote:
> The original patches would, I think, have been pretty scary to
> back-patch, since the infrastructure didn't exist in older branches
> and we were churning a fairly large amount of code. Now that most
> places are fixed and things have
On Wed, Aug 15, 2018 at 07:46:49PM -0400, Dian Fay wrote:
> hi all! I discovered today that the REFRESH MATERIALIZED VIEW documentation
> doesn't mention that only the owner (or a superuser) may actually perform
> the refresh operation. This patch adds a note to that effect.
I think that's a good
On Wed, Aug 15, 2018 at 06:23:40PM -0400, Jonathan S. Katz wrote:
> This was added as an open item by Michael[1]. When the RMT discussed,
> we were able to make arguments both ways (i.e. adjusting the behavior vs.
> not).
>
> Peter, from your analysis it sounds like we should leave it, but I wante
Hi Dian,
> On Aug 15, 2018, at 7:46 PM, Dian Fay wrote:
>
> hi all! I discovered today that the REFRESH MATERIALIZED VIEW documentation
> doesn't mention that only the owner (or a superuser) may actually perform the
> refresh operation. This patch adds a note to that effect.
I played around w
On Wed, Aug 15, 2018 at 09:06:34PM -0400, Jonathan S. Katz wrote:
> I played around with this feature a bit and did see this was the case.
> Also while playing around I noticed the error message was as such:
>
> test=> REFRESH MATERIALIZED VIEW blah;
> ERROR: must be owner of relation
Hi, Hackers,
The attached small patch updates src/backend/utils/errcode.txt.
In the comment of this file, a list of file names generated from this file is
written.
However, the file name of the 'errcodes.sgml' file is incorrect.
The attached patch fixes the incorrect path of errcodes.sgml file na
I feel resorting to the infinitive asks more involvement of the reader,
while leading with the responsible role(s) helps shortcut the process of
determining whether what follows is relevant. Efficiency is always a
virtue, although this is admittedly more than a little academic for a
one-sentenc
> On Aug 15, 2018, at 9:02 AM, Robert Haas wrote:
>
> On Tue, Aug 14, 2018 at 5:14 PM, Mark Dilger wrote:
>> I think you are interpreting the problem too broadly. This is basically
>> just a privilege escalation attack vector.
>
> Hmm. Well, I think you're interpreting the problem too narr
On 2018-Aug-16, Michael Paquier wrote:
> On Mon, Aug 13, 2018 at 01:39:06PM -0400, Robert Haas wrote:
> > The original patches would, I think, have been pretty scary to
> > back-patch, since the infrastructure didn't exist in older branches
> > and we were churning a fairly large amount of code.
There's also clang on Windows, which VS apparently supports. With clang
on Windows PG could even make use of GCC/Clang C extensions :^)
(2018/08/15 23:40), Robert Haas wrote:
Given the comments from the RMT, and also on general principle, it
seems like we really need to get on with committing something here.
It's my understanding you plan to do that, since it's your patch.
When?
I plan to do that late next week as I'll go on le
On Thu, Aug 16, 2018 at 01:18:21AM +, Shinoda, Noriyoshi (PN Japan GCS
Delivery) wrote:
> The attached small patch updates src/backend/utils/errcode.txt.
> In the comment of this file, a list of file names generated from this file is
> written.
> However, the file name of the 'errcodes.sgml'
Applied cleanly for me. Here are my performance test results:
count
-
300
(1 row)
Time: 3167.836 ms (00:03.168)
count
--
1010
(1 row)
Time: 6074.369 ms (00:06.074)
count
---
10001
(1 row)
Time: 8.159 ms
The performance improves substantially in case 2 as adv
Dian Fay writes:
> I feel resorting to the infinitive asks more involvement of the reader,
> while leading with the responsible role(s) helps shortcut the process of
> determining whether what follows is relevant. Efficiency is always a
> virtue, although this is admittedly more than a little a
Mark Dilger writes:
> Go ahead and define some new lexical scope mechanism. I'm probably
> going to move into the 21st century with you and use it. (I mostly
> use "my", not "local", when I write perl code.) But let's treat that as
> a new feature independent of fixing the security problems wit
Hi hackers,
While contemplating plans to use new kinds of OIDs in buffer tags, I
noticed $SUBJECT. It says:
* Check for wraparound of the OID counter. We *must* not return 0
* (InvalidOid); and as long as we have to check that, it seems a good
* idea to skip over everything below FirstNormal
Michael-san,
Thank you for your responsse.
> It seems to me that doc/src/sgml/errcodes-table.sgml is the one generated.
> errcodes.sgml includes just a reference to the table produced.
Oh, I think your opinion is correct.
I attached a modified version.
Regards,
Noriyoshi Shinoda
-Original
Thomas Munro writes:
> That makes it sound like a mere optimisation, but since commit
> 8e18d04d4da user-created objects are not allowed to have OIDs below
> that threshold. So I propose the attached tweak.
+1
regards, tom lane
> On Aug 15, 2018, at 9:15 PM, Michael Paquier wrote:
>
> On Wed, Aug 15, 2018 at 09:06:34PM -0400, Jonathan S. Katz wrote:
>> I played around with this feature a bit and did see this was the case.
>> Also while playing around I noticed the error message was as such:
>>
>> test=> REFRESH M
Hi Tom,
On 2018/08/15 22:27, Tom Lane wrote:
Tatsuro Yamada writes:
Attached patch gives the following query a semicolon for readability.
s/SELECT pg_catalog.set_config ('search_path', '', false)/
SELECT pg_catalog.set_config ('search_path', '', false);/
I'm not exactly convinced t
Hello Jesper,
I was reviewing index-skip patch example and have a comment on it. Example
query “select distinct b from t1” is equivalent to “select b from t1 group by
b”. When I tried the 2nd form of query it came up with different plan, is it
possible that index skip scan can address it as wel
On Wed, Aug 15, 2018 at 12:04:53PM -0400, Robert Haas wrote:
> On Tue, Aug 14, 2018 at 10:44 PM, Noah Misch wrote:
> > Right. For what it's worth, the example I permuted upthread might look like
> > this in a lexical search path world:
> >
> > -- Always secure, even if schema usage does not confo
> "Kaiting" == Kaiting Chen writes:
Kaiting> I'll do some more testing to determine how this behaves in the
Kaiting> presence of multibyte characters in UTF-8.
Excellent, thanks!
--
Andrew (irc:RhodiumToad)
On Wed, Aug 15, 2018 at 10:40:55AM -0500, Nico Williams wrote:
> On Tue, Aug 14, 2018 at 11:50:24PM +, Nasby, Jim wrote:
> > On Aug 14, 2018, at 4:01 PM, Nico Williams wrote:
> > >
> > > On Tue, Aug 14, 2018 at 03:00:55PM +, Robert Haas wrote:
> > >> The more I think about it, the more I
On Thu, Aug 16, 2018 at 5:44 PM, Bhushan Uparkar
wrote:
> I was reviewing index-skip patch example and have a comment on it. Example
> query “select distinct b from t1” is equivalent to “select b from t1 group by
> b”. When I tried the 2nd form of query it came up with different plan, is it
> p
88 matches
Mail list logo
