> "Lætitia" == Lætitia Avrot writes:
[snip patch]
The spec doesn't require the inverse functions (asinh, acosh, atanh),
but surely there is no principled reason to omit them?
--
Andrew (irc:RhodiumToad)
Hola Alvaro,
In reply to https://postgr.es/m/alpine.DEB.2.21.1901102211350.27692@lancre
wherein Fabien wrote:
I'm not very happy with the resulting syntax, but IMO the feature is useful.
My initial design was to copy PL/pgSQL "into" with some "\into" orthogonal
to \; and ;, but the implementa
> "Noah" == Noah Misch writes:
Noah> - # -Wdeclaration-after-statement isn't applicable for C++
Noah> + # -Wdeclaration-after-statement isn't applicable for C++. Specific C
files
Noah> + # disable it, so AC_SUBST the negative form.
Noah> + PERMIT_DECLARATION_AFTER_STATEMENT=
Noah>
On Sat, 2 Feb 2019 at 21:26, Fabien COELHO wrote:
> I do not understand why dump_inserts declaration has left the "flags for
> options" section.
I moved that because it's no longer just a flag. It now stores an int value.
> I'd suggest not to rely on "atoi" because it does not check the argument
> "Noah" == Noah Misch writes:
>> I found it much simpler to strip out -Wdeclaration-after-statement
>> instead:
>>
>> $(RYU_OBJS): override CFLAGS := $(filter-out
>> -Wdeclaration-after-statement,$(CFLAGS))
Noah> The -Wno-declaration-after-statement approach takes eight lines
Noah>
Andrew,
Another question, If the user student is not the owner of the
Schema(additional) and has only USAGE / no privileges, How come it is able
to modify permissions at schema level?
-
--
Thanks,
Rajan.
--
Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html
> "rajan" == rajan writes:
rajan> Andrew,
rajan> Another question, If the user student is not the owner of the
rajan> Schema(additional) and has only USAGE / no privileges, How come
rajan> it is able to modify permissions at schema level?
Because it's not modifying anything that affect
On Sun, Feb 03, 2019 at 06:01:51AM +, Andrew Gierth wrote:
> > "Noah" == Noah Misch writes:
>
> Noah> If the compiler supports -Wdeclaration-after-statement, I add
> Noah> -Wno-declaration-after-statement for imath.c.
>
> I found it much simpler to strip out -Wdeclaration-after-stateme
> "Noah" == Noah Misch writes:
Noah> If the compiler supports -Wdeclaration-after-statement, I add
Noah> -Wno-declaration-after-statement for imath.c.
I found it much simpler to strip out -Wdeclaration-after-statement
instead:
$(RYU_OBJS): override CFLAGS := $(filter-out
-Wdeclaration-af
I happened to notice while looking at code coverage reports that
(1) the portions of create_unique_path() that report that the input
relation is already known unique are no longer reached in our
regression tests;
(2) the loop in relation_has_unique_index_for() that deals with
an exprlist and oprl
pgcrypto bundles a copy of the imath library for arbitrary-precision integer
arithmetic in non-SSL builds. Upstream fixed buffer overflows through the
years, and commit 8b59672 brought those fixes into PostgreSQL. In master, I
would like to fully resynchronize with fresh imath 1.29. We're better
Hi Alvaro,
Thank you so much for taking the time to review the patch and for taking
the time again to sort things
out with me this evening.
> I see that in dtanh() you set errno to 0 before calling tanh(), but 1)
> you don't check for it afterwards (seems like you should be checking for
> ERANG
On Sat, 2 Feb 2019 at 09:31, Robert Haas wrote:
> After having written this code, I'm still torn about whether to go
> further with this design. On the one hand, this is such boilerplate
> code that it's kinda hard to imagine it having too many more bugs; on
> the other hand, as you can see, it's
Andrew Gierth writes:
> [ ryu9.patch ]
I recall having tried some earlier version on my old HPUX dinosaur,
and it worked, but this one doesn't compile:
float.c: In function `float4in':
float.c:240: error: `HUGE_VALF' undeclared (first use in this function)
float.c:240: error: (Each undeclared id
On Sat, Feb 02, 2019 at 08:50:14AM +0200, David Steele wrote:
> How about:
>
> +files created by initdb. This option is ignored
> +on Windows, which does not support
> +POSIX-style group permissions.
Fine for me. Anybody else has an opinion to offer?
--
Michael
signatu
På lørdag 02. februar 2019 kl. 20:01:01, skrev Tom Lane mailto:t...@sss.pgh.pa.us>>: [snip]
There's nothing particularly stopping us from accepting
"materialized" with a D in this syntax, instead of or in addition
to "materialize"; though I hesitate to mention it for fear of
another round of bi
Andres Freund writes:
> On 2019-02-02 11:29:10 -0500, Tom Lane wrote:
>> I think that the original idea here was that we should do as little
>> work as possible "up front", since most index paths will get discarded
>> before we reach createplan.c. But to the extent that that was valid
>> at all,
Further question about this ...
I'm thinking about exactly when indxpath.c should interrogate extensions'
planner support functions. Since it'll cost some cycles to look up and
call such functions, we don't want to do it if there's little or no chance
of getting an index match. Currently, what m
Hi,
On 2019-02-02 11:29:10 -0500, Tom Lane wrote:
> I think that the original idea here was that we should do as little
> work as possible "up front", since most index paths will get discarded
> before we reach createplan.c. But to the extent that that was valid
> at all, it's gotten overtaken by
I wrote:
> I propose that we implement and document this as
> WITH ctename AS [ MATERIALIZE { ON | OFF } ] ( query )
> which is maybe a bit clunky but not awful, and it would leave room
> to generalize it to "AS [ optionname optionvalue [ , ... ] ]" if we
> ever need to. Looking at the prece
THanks for the response, Andrew.
-
--
Thanks,
Rajan.
--
Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html
On 2019-Feb-01, Bossart, Nathan wrote:
> IMHO we could document this feature at a slightly higher level without
> leaving out any really important user-facing behavior. Here's a quick
> attempt to show what I am thinking:
>
> With this option, VACUUM skips all index cleanup behavior and
Hello
In reply to https://postgr.es/m/alpine.DEB.2.21.1901102211350.27692@lancre
wherein Fabien wrote:
> I'm not very happy with the resulting syntax, but IMO the feature is useful.
> My initial design was to copy PL/pgSQL "into" with some "\into" orthogonal
> to \; and ;, but the implementation
I've been poking at the problem discussed in a couple of recent threads
of letting extensions in on the ability to create "lossy index conditions"
for complex operators/functions. The current design for that in
indxpath.c is frankly just a pile of kluges of varying ages. In the
initial pass, the
On Thu, Jan 31, 2019 at 10:18 PM Masahiko Sawada wrote:
>
> Thank you. I'll submit the updated patch set.
>
Attached the latest patch set.
Regards,
--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
From 021a179d7696183394db60aedbd1acb0301ad4b0 Mon Sep
Hi,
On 2019-02-02 05:35:21 -0800, Andres Freund wrote:
> This breaks HOT (and probably also foreign keys), when fast default
> columns are set to NULL, because HeapDetermineModifiedColumns() gets the
> values with heap_getattr(), which returns a spurious NULL for the old
> value (instead of the fa
> "rajan" == rajan writes:
rajan> --with the student user have no privilege how ALTER DEFAULT PRIVILEGES
rajan> works
rajan> *learning=> ALTER DEFAULT PRIVILEGES IN SCHEMA additional GRANT INSERT
ON
rajan> TABLES TO student;
This ALTER only affects the default privileges for tables
On Sat, Feb 2, 2019 at 4:06 AM Amit Kapila wrote:
>
> On Fri, Feb 1, 2019 at 2:49 AM Masahiko Sawada wrote:
> >
> > On Wed, Jan 30, 2019 at 2:06 AM Haribabu Kommi
> > wrote:
> >
> > Thank you. I'll submit the updated patch set.
> >
>
> I don't see any chance of getting this committed in the nex
Hi,
On 2019-02-01 08:24:04 -0800, Andres Freund wrote:
> While working on the patch to slotify trigger.c I got somewhat confused
> by the need to expand tuples in trigger.c:
>
> static HeapTuple
> GetTupleForTrigger(EState *estate,
>EPQState *epqstate,
>Res
On Sat, Feb 2, 2019 at 10:34 PM Graham Leggett wrote:
> On 02 Feb 2019, at 01:57, Thomas Munro wrote:
> > On Sat, Feb 2, 2019 at 9:25 AM Graham Leggett wrote:
> >> Does this support SSL/TLS?
> > I didn't try it myself but I found several claims that it works. I
> > see complaints that it always
Him
On 2019-02-01 14:49:05 -0800, Andres Freund wrote:
> +#ifdef IAM_THE_WRONG_FIX
> if (HeapTupleHeaderGetNatts(tuple.t_data) < relation->rd_att->natts)
> result = heap_expand_tuple(&tuple, relation->rd_att);
> else
> result = heap_copytuple(&tuple);
> +#el
Please help to understand the following. Where the User(who is not the owner
of a table) is able to ALTER DEFAULT PRIVILEGES and GRANT SELECT rights for
all tables Is providing USAGE on schema is enough to do that? How is
this secure?
learning=> select current_user;
current_user
-
On Sat, Feb 2, 2019 at 7:30 AM Amit Kapila wrote:
>
> On Mon, Jan 28, 2019 at 4:40 PM Amit Kapila wrote:
> >
> > On Mon, Jan 28, 2019 at 10:03 AM John Naylor
> > wrote:
>
> In the past few days, we have done a further analysis of each problem
> and tried to reproduce it. We are successful in ge
On 02 Feb 2019, at 01:57, Thomas Munro wrote:
> On Sat, Feb 2, 2019 at 9:25 AM Graham Leggett wrote:
>> On 25 Sep 2018, at 04:09, Thomas Munro wrote:
>>> Some people like to use DNS SRV records to advertise LDAP servers on
>>> their network. Microsoft Active Directory is usually (always?) set
While testing an xidStopLimit corner case, I got this:
3656710 2019-01-05 00:05:13.910 GMT LOG: automatic aggressive vacuum to
prevent wraparound of table "test.pg_toast.pg_toast_826": index scans: 0
3656710 2019-01-05 00:05:16.912 GMT LOG: could not truncate directory
"pg_xact": apparent wrap
Hello David,
Wondering if you have anything else here? I'm happy for the v13
version to be marked as ready for committer.
I still have a few comments.
Patch applies cleanly, compiles, global & local make check are ok.
Typos and style in the doc:
"However, since, by default this op
On Mon, Jan 28, 2019 at 07:29:39PM +0100, Magnus Hagander wrote:
> On Mon, Jan 28, 2019 at 7:26 PM Tom Lane wrote:
> > Stephen Frost writes:
> > >> On Sun, Jan 27, 2019 at 2:28 AM Noah Misch wrote:
> > >>> What are those blocked infrastructure improvements?
> >
> > > The specific improvements we
37 matches
Mail list logo
