> On Mar 3, 2016, at 8:35 AM, Tomas Vondra wrote:
>
> Hi,
>
> On 03/03/2016 12:53 PM, Alexander Korotkov wrote:
>> Hi, Tomas!
>>
>> I've assigned to review this patch.
>>
>> I've checked version estimate-num-groups-v2.txt by Mark
timate the new estimate should
be adjusted. The geometric average is one suggestion, but I don't have
a principled argument for it.
Like I said above, I'm fishing for a decent formula here.
Mark Dilger
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
event, for
example, that the postgres epoch were ever changed.
Mark Dilger
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> On Mar 14, 2016, at 5:12 PM, Vitaly Burovoy wrote:
>
> On 3/14/16, Mark Dilger wrote:
>> The first thing I notice about this patch is that
>> src/include/datatype/timestamp.h
>> has some #defines that are brittle. The #defines have comments explaining
>>
> On Mar 15, 2016, at 8:35 AM, Mark Dilger wrote:
>
>
>> On Mar 14, 2016, at 5:12 PM, Vitaly Burovoy wrote:
>>
>> On 3/14/16, Mark Dilger wrote:
>>> The first thing I notice about this patch is that
>>> src/include/datatype/timestamp.h
>>
, I didn't know about it.
> But in such case (tighten to int32) there are more than two places
> which should be changed. Two more (four with disabled
> HAVE_INT64_TIMESTAMP) constants are not big deal with it.
Please, do not worry about that. I do not mean that your code needs
to b
> On Mar 17, 2016, at 5:05 PM, Peter Geoghegan wrote:
>
> On Thu, Mar 17, 2016 at 4:46 PM, Tom Lane wrote:
>> Alvaro's original complaint that the sentences no longer agree as to
>> person is on-point.
>
> That's reasonable. Still, there are only a few existing instances of
> gendered pronouns
> On Mar 17, 2016, at 5:40 PM, Mark Dilger wrote:
>
>
>> On Mar 17, 2016, at 5:05 PM, Peter Geoghegan wrote:
>>
>> On Thu, Mar 17, 2016 at 4:46 PM, Tom Lane wrote:
>>> Alvaro's original complaint that the sentences no longer agree as to
>>
WIP patch to comments and documentation. Note that I ignored the release notes,
as I don't know if it is appropriate to change those retrospectively. A few of
the
changes make the prose worse and will likely be rejected, but I included the
best
change that came to mind as a starting point for c
ind throwing
them out; as I said, I don't have an opinion on the politics.
Please, don't waste your time if you have actual features to implement.
Regards,
Mark Dilger
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> On Jan 13, 2016, at 9:13 AM, Tom Lane wrote:
>
> Simon Riggs writes:
>> On 13 January 2016 at 14:48, Noah Misch wrote:
>>> I've noticed commits, from a few of you, carrying pgindent changes to lines
>>> the patch would not otherwise change.
>
>> Could we review again why this matters?
>
>
#x27;d say that your patch does what you claim it does, and it
applies
cleanly, and passes the regression tests with my included modifications. I
think there
needs to be some discussion on the list about whether the patch is a good idea.
Mark Dilger
diff --git a/src/backend/utils/adt/selfu
> On Feb 25, 2016, at 3:16 PM, Mark Dilger wrote:
>
>
>> On Feb 23, 2016, at 5:12 PM, Tomas Vondra
>> wrote:
>>
>>
>>
>> So much better. Clearly, there are cases where this will over-estimate the
>> cardinality - for example when the val
> On Feb 25, 2016, at 4:59 PM, Tomas Vondra
> wrote:
>
> Hi,
>
> On 02/26/2016 12:16 AM, Mark Dilger wrote:
>>
>> It is not hard to write test cases where your patched version overestimates
>> the number of rows by a very similar factor as the old code un
/commands/proclang.c, line 466.
src/backend/commands/dbcommands.c, lines 1263, 1489, 1606, 1746.
Am I overlooking some reason why the code is correct as is? If not,
I am attaching a patch that applies cleanly for me against master,
compiles, and passes the regression tests.
Thanks,
Mark Dilger
e project's coding standards?
Would patches to not cast away const be considered?
Thanks,
Mark Dilger
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Friends, per the recent thread "gratuitous casting away const", the
assignment on line 1247 of localtime.c has const lvalue and rvalue,
yet casts through (char *) rather than (const char *). Fix attached.
Mark Dilger
localtime.c.patch
Description: Binary data
--
Sent via pgs
> On Sep 20, 2016, at 1:06 PM, Tom Lane wrote:
>
> Mark Dilger writes:
>> Would patches to not cast away const be considered?
>
> In general, yes, but I'm not especially in favor of something like this:
>
>> bool
>> PageIndexTupl
> On Sep 22, 2016, at 9:14 AM, Tom Lane wrote:
>
> I'd call this kind of a wash, I guess. I'd be more excited about it if
> the change allowed removal of an actual cast-away-of-constness somewhere.
>
> I suppose it's a bit of a chicken and egg situation, in that the lack
> of const markings on
wrench in the works.
Is this a bug? Do I just have to live with the unfortunate lack of
orthogonality in the callback mechanisms? At the very least, there
should perhaps be some documentation about how all this is intended
to work.
Thanks, please find my work-in-progress attempt and constify-
have converted the casts to not cast
away const. Please find my changes, attached.
Mark Dilger
comparators.patch.1
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
const doesn't seem to
conflict with any code in the source tree.
Since this may be seen as an external API change, I kept
these changes in their own patch submission, so that it can
be rejected separately if need be.
Mark Dilger
filename.patch.1
Description: Binary data
--
Sent via pgsql-hacke
Friends,
here is another patch, this time fixing the casting away of const
in the regex code.
Mark Dilger
regex.patch.1
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
> I think the better fix here is to simply remove the typedef. It doesn't
> seem to have much of a benefit, and makes using correct types harder as
> demonstrated here. We don't even use it internally in fd.c..
>
Fine by me.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or
.
tsrank.c contains some arguably correct casts which I found slightly
less correct than an alternative that I've attached. I'm pretty indifferent
on this one, and just as happy if it is not included.
Mark Dilger
tidy.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgs
> Comments, notes?
How would variables behave on transaction rollback?
CREATE TEMP VARIABLE myvar;
SET myvar := 1;
BEGIN;
SET myvar := 2;
COMMIT;
BEGIN;
SET myvar := 3;
ROLLBACK;
SELECT myvar;
How would variables behave when modified in a procedure
that aborts rather than returning cleanly?
m
> On Oct 31, 2017, at 7:46 AM, Peter Eisentraut
> wrote:
>
> Here is a patch that adds const decorations to many char * arguments in
> functions. It should have no impact otherwise; there are very few code
> changes caused by it. Some functions have a strtol()-like behavior
> where they take
> On Sep 12, 2017, at 2:06 PM, Tomas Vondra
> wrote:
>
> Attached is an updated version of the patch, dealing with fallout of
> 821fb8cdbf700a8aadbe12d5b46ca4e61be5a8a8 which touched the SGML
> documentation for CREATE STATISTICS.
Your patches need updating.
Tom's commit 471d55859c11b40059aef
> On Nov 10, 2017, at 3:58 PM, Stephen Frost wrote:
>
> Michael, Tom,
>
> * Michael Paquier (michael.paqu...@gmail.com) wrote:
>> On Fri, Nov 10, 2017 at 10:00 AM, Tom Lane wrote:
>>> Stephen Frost writes:
I'm guessing no, which essentially means that *we* consider access to
lo_impo
> On Sep 27, 2016, at 11:25 PM, Heikki Linnakangas wrote:
>
> On 09/28/2016 02:35 AM, Mark Dilger wrote:
>> The function
>>
>> static void xlog_outdesc(StringInfo buf, XLogReaderState *record);
>>
>> in src/backend/access/transam/xlog.c is called by XLo
S
CC = @CC@
GCC = @GCC@
SUN_STUDIO_CC = @SUN_STUDIO_CC@
-CFLAGS = @CFLAGS@
+CFLAGS = @CFLAGS@ -Werror
CFLAGS_VECTOR = @CFLAGS_VECTOR@
CFLAGS_SSE42 = @CFLAGS_SSE42@
That adds -Werror to the compilation of sources but not to the compilation
of configure test programs. I'd be happy to hea
ive for platforms/compilers where we
know there aren't spurious warnings? That would make detecting
unintentionally introduced warnings simpler, without the use of
COPT. Perhaps where the compiler is GCC or CLANG, and the
platform is x86_64 redhat, something like that?
Mark Dilger
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> On Feb 17, 2017, at 3:37 PM, Peter Eisentraut
> wrote:
>
> On 2/17/17 16:13, Mark Dilger wrote:
>> + PGAC_PROG_CC_CFLAGS_OPT([-Wc++-compat])
>
> If your compiler isn't warning about anything with that, then there is
> something wrong with it.
$ gcc --v
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
On my MacBook, `make check-world` gives differences in the contrib module
> On Mar 7, 2017, at 1:43 PM, Mark Dilger wrote:
>
> On my MacBook, `make check-world` gives differences in the contrib modules:
I get the same (or similar -- didn't check) regression failure on CentOS, so
this
doesn't appear to be MacBook / hardware specific.
Mark Dilger
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
On linux/gcc the patch generates a warning in nodeAgg.c that is fairly ea
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
Hi Peter,
I like the patch so far, and it passes all the regression test
> On Mar 8, 2017, at 2:30 AM, Andrew Gierth wrote:
>
>>>>>> "Mark" == Mark Dilger writes:
>
> Mark> On linux/gcc the patch generates a warning in nodeAgg.c that is
> Mark> fairly easy to fix. Using -Werror to make catching the error
>
> On Mar 8, 2017, at 5:47 AM, Andrew Gierth wrote:
>
>>>>>> "Mark" == Mark Dilger writes:
>
> Mark> On my MacBook, `make check-world` gives differences in the
> Mark> contrib modules:
>
> Thanks! Latest cleaned up version of patch is
8, 2017, at 8:00 AM, Mark Dilger wrote:
>
>
>> On Mar 8, 2017, at 5:47 AM, Andrew Gierth
>> wrote:
>>
>>>>>>> "Mark" == Mark Dilger writes:
>>
>> Mark> On my MacBook, `make check-world` gives differences in the
>> Mark&
> On Mar 8, 2017, at 9:40 AM, Andrew Gierth wrote:
>
>>>>>> "Mark" == Mark Dilger writes:
>
> Mark> Hi Andrew,
>
> Mark> Reviewing the patch a bit more, I find it hard to understand the
> Mark> comment about passing -1 as a flag fo
ives, so it seems this was just not considered or not yet in
>> existence when the error codes were introduced. Here is a patch to
>> correct it.
>
> committed
Perhaps you should add something to the release notes. Somebody could be
testing for the old error code.
Mark Dilger
-
> On Mar 21, 2017, at 2:13 PM, David Steele wrote:
>
> Hi Mark,
>
> On 3/9/17 3:34 PM, Peter Eisentraut wrote:
>> On 3/7/17 18:27, Mark Dilger wrote:
>>> You appear to be using a #define macro to wrap a function of the same name
>>> with the code:
>&g
> On Mar 22, 2017, at 8:09 AM, Mark Dilger wrote:
>
>
>> On Mar 22, 2017, at 7:55 AM, Andrew Gierth
>> wrote:
>>
>> [snip]
>>
>> This thread seems to have gone quiet - is it time for me to just go
>> ahead and commit the thing anyway? Any
> On Mar 23, 2017, at 11:22 AM, Andrew Gierth
> wrote:
>
>>>>>> "Mark" == Mark Dilger writes:
>
> Mark> You define DiscreteKnapsack to take integer weights and double
> Mark> values, and perform the usual Dynamic Programming algorithm to
&
> On Mar 28, 2017, at 8:34 AM, Dave Page wrote:
>
> On Tue, Mar 28, 2017 at 11:31 AM, Peter Eisentraut
> wrote:
>> This patch touches the pg_buffercache and pg_freespacemap extensions,
>> but there appear to be some files missing.
>
> Are you looking at an old version? There was one where I fo
> On Mar 28, 2017, at 9:55 AM, Robert Haas wrote:
>
> On Tue, Mar 28, 2017 at 12:47 PM, Dave Page wrote:
>>> I don't see any precedent in the code for having a hardcoded role, other
>>> than
>>> superuser, and allowing privileges based on a hardcoded test for membership
>>> in that role. I'm
> On Mar 28, 2017, at 9:47 AM, Dave Page wrote:
>
>> Does
>> pg_read_all_stats still have access to stats for mysecuretable?
>
> Yes, because the ACL on the table controls reading/writing the data in
> the table. It doesn't have any bearing on any kind of table metadata.
> A user who has no pri
> On Mar 28, 2017, at 11:06 AM, Mark Dilger wrote:
>
>
>> On Mar 28, 2017, at 9:47 AM, Dave Page wrote:
>>
>>> Does
>>> pg_read_all_stats still have access to stats for mysecuretable?
>>
>> Yes, because the ACL on the table controls readin
> On Mar 28, 2017, at 11:52 AM, Tom Lane wrote:
>
> Mark Dilger writes:
>> After a bit of introspection, I think what is really bothering me is not the
>> inability to revoke permissions, since as you say I can choose to not assign
>> the role to anybody. What both
> On Mar 28, 2017, at 1:17 PM, Tom Lane wrote:
>
> Mark Dilger writes:
>> I don't see anything wrong with adding roles in pg_authid.h with a #define'd
>> Oid. That's actually pretty helpful for anyone writing code against the
>> database,
>> a
Varbit's bitoctetlength function
could detoast only the header ala PG_DETOAST_DATUM_SLICE to return the
octet length, rather than detoasting the whole thing. But that seems a
different
issue, and patches to change that might have been rejected in the past so far
as I
know, so I did not a
> On Apr 5, 2017, at 1:12 PM, Tom Lane wrote:
>
> Mark Dilger writes:
>> I have written a patch to fix these macro definitions across src/ and
>> contrib/.
>> Find the patch, attached. All regression tests pass on my Mac laptop.
>
> Thanks for doing the le
Peter,
Can you perhaps initialize the variable 'address' to suppress the warning?
Thanks.
Mark Dilger
tablecmds.c:5984:6: warning: variable 'address' is used uninitialized whenever
'if' condition is false [-Wsometimes-uninitia
> On Apr 6, 2017, at 8:33 AM, Peter Eisentraut
> wrote:
>
> On 4/6/17 10:59, Mark Dilger wrote:
>> Can you perhaps initialize the variable 'address' to suppress the warning?
>> Thanks.
>
> A potential fix for this has been pushed.
It works for me.
> On Apr 8, 2017, at 5:13 PM, Tom Lane wrote:
>
> I wrote:
>> Robert Haas writes:
>>> On Sat, Apr 8, 2017 at 3:57 PM, Tom Lane wrote:
>>> I think it's pretty dubious to change this, honestly. Just because it
>>> would have caught this one bug doesn't make it an especially valuable
>>> thing i
> On Apr 8, 2017, at 6:38 PM, Mark Dilger wrote:
>
>
>> On Apr 8, 2017, at 5:13 PM, Tom Lane wrote:
>>
>> I wrote:
>>> Robert Haas writes:
>>>> On Sat, Apr 8, 2017 at 3:57 PM, Tom Lane wrote:
>>>> I think it's pretty dubious
> On Apr 8, 2017, at 6:48 PM, Mark Dilger wrote:
>
>
>> On Apr 8, 2017, at 6:38 PM, Mark Dilger wrote:
>>
>>
>>> On Apr 8, 2017, at 5:13 PM, Tom Lane wrote:
>>>
>>> I wrote:
>>>> Robert Haas writes:
>>>>> O
> On Apr 8, 2017, at 7:35 PM, Tom Lane wrote:
>
> Mark Dilger writes:
>> This is very near where the original crash reported in this thread was
>> crashing, probably only
>> different due to the extra lines of Assert that were added. Am I missing
>> some p
> On Apr 8, 2017, at 7:41 PM, Mark Dilger wrote:
>
>
>> On Apr 8, 2017, at 7:35 PM, Tom Lane wrote:
>>
>> Mark Dilger writes:
>>> This is very near where the original crash reported in this thread was
>>> crashing, probably only
>>>
Hackers,
In src/pl/plpgsql/src/pl_exec.c: exec_run_select intentionally does not
allow a parallel plan if a portal will be returned. This has the practical
consequence that a common coding practice (at least for me) of doing
something like:
create function myfunc(arg1 text, arg2 text) returns se
> On Jun 29, 2017, at 9:14 PM, Amit Kapila wrote:
>
> On Fri, Jun 30, 2017 at 9:25 AM, Mark Dilger wrote:
>> Hackers,
>>
>> In src/pl/plpgsql/src/pl_exec.c: exec_run_select intentionally does not
>> allow a parallel plan if a portal will be returned. This
> On Jun 29, 2017, at 8:55 PM, Mark Dilger wrote:
>
>
> Changing myfunc to create a temporary table, to execute the sql to populate
> that temporary table, and to then loop through the temporary table's rows
> fixes the problem. For the real-world example where
> On Jul 3, 2017, at 10:25 PM, Amit Kapila wrote:
>
> On Mon, Jul 3, 2017 at 8:57 PM, Simon Riggs wrote:
>> On 30 June 2017 at 05:14, Amit Kapila wrote:
>>
>>> This is explained in section 15.2 [1], refer below para:
>>> "The query might be suspended during execution. In any situation in
>>>
> On Jul 5, 2017, at 5:30 AM, Amit Kapila wrote:
>
> On Wed, Jul 5, 2017 at 9:44 AM, Mark Dilger wrote:
>>
>>> On Jul 3, 2017, at 10:25 PM, Amit Kapila wrote:
>>>
>>> On Mon, Jul 3, 2017 at 8:57 PM, Simon Riggs wrote:
>>>> On 30 June
> On Jul 7, 2017, at 2:53 AM, Emrul wrote:
>
> Tom, thank you for that pointer. I get now that it is not free and therefore
> why its not something that should be changed by default.
>
> I guess the problem is 'build your own copy' (i.e. compiling from source) is
> something that sends most DB
> On Jul 15, 2017, at 3:00 PM, Tom Lane wrote:
>
> The types abstime, reltime, and tinterval need to go away, or be
> reimplemented, sometime well before 2038 when they will overflow.
> It's not too soon to start having a plan for that, especially seeing
> that it seems to take a decade or more
> On Jul 17, 2017, at 12:54 PM, Mark Dilger wrote:
>
>
>> On Jul 15, 2017, at 3:00 PM, Tom Lane wrote:
>>
>> The types abstime, reltime, and tinterval need to go away, or be
>> reimplemented, sometime well before 2038 when they will overflow.
>> It&#x
> On Jul 17, 2017, at 2:14 PM, Tom Lane wrote:
>
> Mark Dilger writes:
>>> On Jul 17, 2017, at 12:54 PM, Mark Dilger wrote:
>> On Jul 15, 2017, at 3:00 PM, Tom Lane wrote:
>>>> The types abstime, reltime, and tinterval need to go away, or be
>>>&g
> On Jul 17, 2017, at 3:12 PM, Tom Lane wrote:
>
> Mark Dilger writes:
>>> On Jul 17, 2017, at 2:14 PM, Tom Lane wrote:
>>> Well, if you or somebody is willing to do the legwork, I'd be on board
>>> with a plan that says that every 68 years we redefine
> On Jul 17, 2017, at 3:56 PM, Tom Lane wrote:
>
> Mark Dilger writes:
>> On Jul 17, 2017, at 3:12 PM, Tom Lane wrote:
>>> Now, this should mostly work conveniently, except that we have
>>> +/-infinity (NOEND_ABSTIME/NOSTART_ABSTIME) to deal with ... It mig
> On Jul 17, 2017, at 3:12 PM, Tom Lane wrote:
>
> Mark Dilger writes:
>>> On Jul 17, 2017, at 2:14 PM, Tom Lane wrote:
>>> Well, if you or somebody is willing to do the legwork, I'd be on board
>>> with a plan that says that every 68 years we redefine
> On Jul 17, 2017, at 2:34 PM, Mark Dilger wrote:
>
>>
>> On Jul 17, 2017, at 2:14 PM, Tom Lane wrote:
>>
>> Mark Dilger writes:
>>>> On Jul 17, 2017, at 12:54 PM, Mark Dilger wrote:
>>> On Jul 15, 2017, at 3:00 PM, Tom Lane wrote:
>
> On Jul 18, 2017, at 9:13 PM, Mark Dilger wrote:
>
>>
>> On Jul 17, 2017, at 2:34 PM, Mark Dilger wrote:
>>
>>>
>>> On Jul 17, 2017, at 2:14 PM, Tom Lane wrote:
>>>
>>> Mark Dilger writes:
>>>>> On Jul 17, 2017,
> On Jul 19, 2017, at 10:23 AM, Robert Haas wrote:
>
> On Wed, Jul 19, 2017 at 1:12 PM, Tom Lane wrote:
>>> Doesn't this plan amount to breaking pg_upgrade compatibility and
>>> hoping that nobody notice?
>>
>> Well, what we'd need to do is document that the type is only meant to be
>> used to
> On Jul 19, 2017, at 9:53 AM, Robert Haas wrote:
>
> On Mon, Jul 17, 2017 at 6:12 PM, Tom Lane wrote:
>> So, thinking about how that would actually work ... the thing to do in
>> order to preserve existing on-disk values is to alternate between signed
>> and unsigned interpretations of abstime
> On Aug 10, 2017, at 11:20 AM, Robert Haas wrote:
>
> On Wed, Jul 5, 2017 at 12:14 AM, Mark Dilger wrote:
>> I can understand this, but wonder if I could use something like
>>
>> FOR I TOTALLY PROMISE TO USE ALL ROWS rec IN EXECUTE sql LOOP
>> ...
>> E
> On Apr 22, 2017, at 11:40 AM, Tom Lane wrote:
>
> I wrote:
>> Whoa. This just turned into a much larger can of worms than I expected.
>> How can it be that processes are getting assertion crashes and yet the
>> test framework reports success anyway? That's impossibly
>> broken/unacceptable.
> On Apr 5, 2017, at 1:27 PM, Mark Dilger wrote:
>
>
>> On Apr 5, 2017, at 1:12 PM, Tom Lane wrote:
>>
>> Mark Dilger writes:
>>> I have written a patch to fix these macro definitions across src/ and
>>> contrib/.
>>> Find the patch,
ckward too. Is there a bug there?
>
> I remain of the opinion that if we can't tell from the transmitted
> data whether a timeline switch has caused the position to go backward,
> then that's a protocol shortcoming that ought to be fixed.
The recent fix in 546c13e11b29a5408b9d6a6e3cca301380b47f7f has
noise if this is already common knowledge. Also, if I'm
wrong,
I'd appreciate a pointer to the test that I am failing to find.
Thanks,
Mark Dilger
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.or
> On May 9, 2017, at 12:18 AM, Amit Langote
> wrote:
>
> Hi,
>
> On 2017/05/05 9:38, Mark Dilger wrote:
>> Hackers,
>>
>> just FYI, I cannot find any regression test coverage of this part of the
>> grammar, not
>> even in the contrib/ direct
tored procedures that work in support
of the middle tier might want it for locale information, etc. As things
currently stand, there is no good way to get this passed all the way down
into the database stored procedure that needs it, given that you are
typically calling down through third party c
> On May 9, 2017, at 3:14 PM, Chapman Flack wrote:
>
> On 05/09/2017 01:25 PM, Mark Dilger wrote:
>
>> Consensus, no, but utility, yes.
>>
>> In three tier architectures there is a general problem that the database
>> role used by the middle tier to con
s are a bit large; let
me know if you need them.
I built using the command
./configure --enable-cassert --enable-tap-tests && make -j4 && make check
Mark Dilger
to_reproduce_bug.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.o
> On May 14, 2017, at 11:02 PM, Amit Langote
> wrote:
>
> On 2017/05/14 12:03, Mark Dilger wrote:
>> Hackers,
>>
>> I discovered a reproducible crash using event triggers in the current
>> development version, 29c7d5e483acaa74a0d06dd6c70b320bb315.
> On May 15, 2017, at 6:49 AM, Mark Dilger wrote:
>
> I can confirm that this fixes the crash that I was seeing. I have read
> through the patch briefly, but will give it a more thorough review in the
> next few hours.
My only negative comment is that your patch follows a pre
d opfamily. I can imagine clever hash
functions that preserve certain properties of the incoming data, and check
constraints in development versions of the database that help verify the hash
is not violating those properties.
That's not to say such hash functions must be allowed in the has
> On May 15, 2017, at 9:37 PM, Amit Langote
> wrote:
>
> On 2017/05/16 1:18, Mark Dilger wrote:
>>
>>> On May 15, 2017, at 6:49 AM, Mark Dilger wrote:
>>>
>>> I can confirm that this fixes the crash that I was seeing. I have read
>>&
pedantry. Patch attached.
Mark Dilger
syscache.patch.0
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
tend the grammar and behavior in this direction,
maybe temp_tablespaces would work that way? I'm not so familiar with what
the temp_tablespaces GUC is for -- only ever implemented what I described
above.
Mark Dilger
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
> On May 31, 2017, at 6:04 AM, Bruce Momjian wrote:
>
> On Wed, May 31, 2017 at 07:53:53AM -0400, Robert Haas wrote:
>> On Tue, May 30, 2017 at 6:50 PM, Mark Dilger wrote:
>>>> On May 29, 2017, at 11:53 AM, Bruce Momjian wrote:
>>>> Right now we don&#
> On May 31, 2017, at 7:58 AM, Bruce Momjian wrote:
>
> On Wed, May 31, 2017 at 07:53:22AM -0700, Mark Dilger wrote:
>>> Just to clarify, the TEMPORARY clause would allow the tablespace to
>>> start up empty, while normal tablespaces can't do that, right? One
fields
for those two tables could show up as different.
Can we perhaps remove the :location field here? If not, could somebody
please defend why this belongs in the catalog entries for the table? Sorry
if I am missing something obvious...
Thanks,
Mark Dilger
--
Sent via pgsql-hackers mailing
> On May 31, 2017, at 2:49 PM, Alvaro Herrera wrote:
>
> Mark Dilger wrote:
>> Hackers,
>>
>> recent changes have introduced the :location field to the partboundspec
>> in pg_catalog.pg_class. This means that if two identical tables with
>> identical p
> On May 31, 2017, at 3:17 PM, Andres Freund wrote:
>
> On 2017-05-31 15:06:06 -0700, Mark Dilger wrote:
>> That's cold comfort, given that most users will be looking at the pg_class
>> table and not writing C code that compares Node objects. I wrote a bit of
>
> On May 31, 2017, at 3:42 PM, Andres Freund wrote:
>
> On 2017-05-31 15:38:58 -0700, Mark Dilger wrote:
>>> Normal users aren't going to make sense of node trees in the first
>>> place. You should use pg_get_expr for it:
>>> postgres[3008][1]=# S
> On May 31, 2017, at 4:00 PM, Alvaro Herrera wrote:
>
> Mark Dilger wrote:
>
>>>>
>>>>
> On May 31, 2017, at 6:32 PM, Amit Langote
> wrote:
>
> On 2017/06/01 4:50, Robert Haas wrote:
>> On Wed, May 31, 2017 at 3:40 PM, Mark Dilger wrote:
>>> recent changes have introduced the :location field to the partboundspec
>>> in pg_catalog.pg_clas
> On Jun 1, 2017, at 6:31 AM, Tom Lane wrote:
>
> Mark Dilger writes:
>> When you guys commit changes that impact partitioning, I notice, and change
>> my code to match. But in this case, it seemed to me the change that got
>> committed was not thought throug
1 - 100 of 248 matches
Mail list logo
