> 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 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 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
> 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 Sep 26, 2017, at 10:36 AM, Bruce Momjian wrote:
>
> On Tue, Sep 26, 2017 at 10:23:55AM -0700, Mark Dilger wrote:
>> The comment that I think needs updating is:
>>
>> # METHOD can be "trust", "reject", "md5", "password",
The comment that I think needs updating is:
# METHOD can be "trust", "reject", "md5", "password", "scram-sha-256",
# "gss", "sspi", "ident", "peer", "pam", "ldap", "radius" or "cert".
The "md5" option no longer works, as discussed in other threads.
mark
--
Sent via pgsql-hackers mailing lis
> On Sep 12, 2017, at 1:07 PM, Tom Lane wrote:
>
> [ changing subject line to possibly draw more attention ]
>
> Mark Dilger writes:
>>> On Apr 5, 2017, at 9:23 AM, Tom Lane wrote:
>>> In short, if you are supposed to write
>>> FOO *val = PG_
> 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 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 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 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 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 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: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 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
> 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 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 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 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 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 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
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 4, 2017, at 2:19 PM, Andres Freund wrote:
>
> On 2017-06-04 14:16:14 -0700, Mark Dilger wrote:
>> Sorry, I was not clear. What I meant to get at was that if you remove from
>> the
>> executor all support for SRFs inside case statements, you might for
> On Jun 4, 2017, at 12:35 PM, Andres Freund wrote:
>
> Hi Mark,
>
> On 2017-06-04 11:55:03 -0700, Mark Dilger wrote:
>>> Yea, I'm not a big fan of the either the pre v10 or the v10 behaviour of
>>> SRFs inside coalesce/case. Neither is really resonab
> On Jun 4, 2017, at 11:55 AM, Mark Dilger wrote:
>
> SELECT x, CASE WHEN y THEN SUM(generate_series(1,z)) ELSE 5 END
> FROM table_with_columns_x_and_y;
Sorry, this table is supposed to be the same as the previous one,
table_with_columns_x_and_y_and_z
--
Sent via p
row per table row where y is false. That could be changed
with an aggregate function such as:
SELECT x, CASE WHEN y THEN SUM(generate_series(1,z)) ELSE 5 END
FROM table_with_columns_x_and_y;
Which to me gives one output row per table row regardless of whether y
is true.
Thanks, and my apologies if I am merely lacking sufficient imagination to
think of a proper example.
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
rationale. Maybe you'd like to complain that every one of those
> rationales is wrongheaded but I do not think you will get far.
>
> I think the best advice for Mark is to look at pg_get_expr() output and
> see if that matches.
Yes, I'm already doing that based on t
> 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
> 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 May 31, 2017, at 4:00 PM, Alvaro Herrera wrote:
>
> Mark Dilger wrote:
>
>>>>
>>>>
> 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 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 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
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 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
> 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
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
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
> 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
>>&
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 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
> 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.
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 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
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 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
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
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
> 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,
> 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 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
>>>
> 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 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 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 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 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.
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 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
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 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
> 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 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 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 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 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 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 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 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
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 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
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 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
> 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
>
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
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
> 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 my MacBook, `make check-world` gives differences in the contrib module
> 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
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
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
chance you could add some documentation about how this function
is intended to be used and defined?
See InitTupleHashIterator in src/include/nodes/execnodes.h
Thanks,
Mark Dilger
> On Oct 9, 2016, at 4:38 PM, Andres Freund wrote:
>
> Hi,
>
> Attached is an updated version of th
> 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
.
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
> 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
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
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
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
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-
> 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
> 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
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
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
/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
> On Jun 20, 2016, at 1:00 PM, David G. Johnston
> wrote:
>
> On Mon, Jun 20, 2016 at 3:08 PM, Mark Dilger wrote:
>
> > Do you have a problem with the human form and machine forms of the version
> > number being different in this respect? I don't - for me t
> On Jun 20, 2016, at 11:30 AM, David G. Johnston
> wrote:
>
> On Mon, Jun 20, 2016 at 2:14 PM, Mark Dilger wrote:
>
> > On Jun 20, 2016, at 11:06 AM, Joshua D. Drake
> > wrote:
> >
> > On 06/20/2016 10:45 AM, Mark Dilger wrote:
> >
> >&
> On Jun 20, 2016, at 11:06 AM, Joshua D. Drake wrote:
>
> On 06/20/2016 10:45 AM, Mark Dilger wrote:
>
>>> Now maybe you have some other idea in mind, but I don't quite
>>> understand what it is.
>>
>> I do, indeed, and here it is:
>>
&g
> On Jun 20, 2016, at 9:38 AM, David G. Johnston
> wrote:
>
> On Mon, Jun 20, 2016 at 12:28 PM, Mark Dilger wrote:
>
> > On Jun 20, 2016, at 8:53 AM, Mark Dilger wrote:
> >
> >
> > This is not a plea for keeping the three part versioning system. It
> On Jun 20, 2016, at 9:43 AM, Robert Haas wrote:
>
> On Mon, Jun 20, 2016 at 12:26 PM, Mark Dilger wrote:
>>> In practical effect that is exactly what your proposal does. You just feel
>>> better because you defined when B is allowed to change even though it nev
1 - 100 of 248 matches
Mail list logo