On Saturday, April 17, 2021, Tom Lane wrote:
> "David G. Johnston" writes:
> > On Sat, Apr 17, 2021 at 10:58 AM Vladimír Houba ml.
> > wrote:
> >> Another nice feature would be a function that can be called from a sql
> >> statement and would
On Sat, Apr 17, 2021 at 12:58 PM Vladimír Houba ml.
wrote:
> I use ctid as a row identifier within a transaction in a Java application.
>
This doesn't present a very compelling argument since an actual user
declared primary key is what is expected to be used as a row identifier.
And as those are
On Sat, Apr 17, 2021 at 10:58 AM Vladimír Houba ml.
wrote:
> I propose to implement a builtin and efficient bidirectional cast between
> ctid and bigint types.
>
>
Why?
> Another nice feature would be a function that can be called from a sql
> statement and would throw an exception when execut
On Wed, Apr 7, 2021, 09:29 FATIHI Ayoub wrote:
> Hi postgres community,
> I am willing to participate in GSoC to speed up the build of the gist
> index in postgis, which is based on postgresql.
>
You should mention and link to where you cross-posted this to Reddit.
On Wed, Apr 7, 2021 at 7:13 AM Hellmuth Vargas wrote:
>
> ?? Well, the truth does not show the data that I request, what I request
> is that by configuring some parameter, the size of the obtained records can
> be obtained from the execution of a query something similar to the
> log_min_duration_
On Fri, Mar 12, 2021 at 1:36 PM Tom Lane wrote:
> Pavel Stehule writes:
> > pá 12. 3. 2021 v 21:08 odesílatel Tom Lane napsal:
> >> I attach a v3 that I like better, although there's room to disagree
> >> about that.
>
> > I am not sure if people can understand the "optimizable command" term.
>
On Fri, Mar 12, 2021 at 7:35 AM Laurenz Albe
wrote:
> On Fri, 2021-03-12 at 10:16 +0100, I wrote:
> > After sleeping on it, I have come to think that it is excessive to write
> > so much documentation for a feature that is that unimportant.
> >
> > It takes some effort to come up with a good use
On Thursday, March 11, 2021, Bossart, Nathan wrote:
> Thanks for reviewing.
>
> On 3/11/21, 6:59 AM, "Laurenz Albe" wrote:
> > I have had a look at the patch, and while I agree that this should
> > be documented, I am not happy with the patch as it is.
> >
> > I think we should *not* document th
On Thu, Mar 11, 2021 at 7:58 AM Laurenz Albe
wrote:
> I think we should *not* document that under "server configuration".
> This is confusing and will lead people to think that a role is
> a configuration parameter. But you cannot add
>
>role = myrole
>
> to "postgresql.conf". A role is not
On Tue, Mar 9, 2021 at 10:45 AM Pavel Stehule
wrote:
>
>
> út 9. 3. 2021 v 18:03 odesílatel David Steele
> napsal:
>
>> On 11/30/20 10:37 AM, Pavel Stehule wrote:
>> > po 30. 11. 2020 v 16:06 odesílatel David G. Johnston
>> >
>> > ok
>>
On Tuesday, March 9, 2021, David Steele wrote:
>
> Further, I think we should close this entry at the end of the CF if it
> does not attract committer interest. Tom is not in favor of the patch and
> it appears Alexander decided not to commit it.
>
Pavel re-reviewed it and was fine with ready-to
On Mon, Mar 8, 2021 at 4:41 PM David G. Johnston
wrote:
> On Thu, Feb 18, 2021 at 6:18 PM Bossart, Nathan
> wrote:
>
>> On 2/17/21 2:12 PM, David G. Johnston wrote:
>> > On Wednesday, February 17, 2021, Bossart, Nathan > > <mailto:bossa...@amazon.com>>
On Thu, Feb 18, 2021 at 6:18 PM Bossart, Nathan wrote:
> On 2/17/21 2:12 PM, David G. Johnston wrote:
> > On Wednesday, February 17, 2021, Bossart, Nathan > <mailto:bossa...@amazon.com>> wrote:
> >
> >
> > postgres=# ALTER ROLE test1 SET ROLE test
On Thu, Feb 25, 2021 at 8:37 AM Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
> On 18.02.21 19:14, Peter Eisentraut wrote:
> > On 18.02.21 17:11, David G. Johnston wrote:
> >> The OP was doing a course based on Oracle and was confused regarding
> >>
On Wed, Mar 3, 2021 at 5:45 PM Justin Pryzby wrote:
> I'm proposing some minor changes.
>
>
Some additional tweaks/comments for the documentation with the edit
proposed edits:
(edit) + PQresultStatus, will report a
Remove the comma
(orig) + the failed operation are skipped entirely. Th
On Mon, Mar 8, 2021 at 8:48 AM Fujii Masao
wrote:
>
> Thanks for updating the patch! I applied cosmetic changes to that.
> Patch attached. Barring any objection, I will commit this version.
>
Read over the patch and it looks good.
One minor "the" omission (in a couple of places, copy-paste styl
On Saturday, March 6, 2021, David Fetter wrote:
>
> > > SELECT BIT_XOR(b ORDER BY a, c).../* works */
> > > SELECT BIT_XOR(b) OVER (ORDER BY a, c)... /* works */
> > > SELECT BIT_XOR(b) FROM... /* errors out */
> >
> >
> > Why would such an error be necessary,
On Thu, Feb 18, 2021 at 9:00 AM Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
>
> And that seems definitely wrong. Declaring c1 in the above example as
> FOR UPDATE or FOR SHARE does not change the result. I think this
> discussion is mixing up the concept of cursor sensitivity wi
On Wednesday, February 17, 2021, Bossart, Nathan
wrote:
>
> postgres=# ALTER ROLE test1 SET ROLE test2;
> ALTER ROLE
>
I would not have expected this to work - “role” isn’t a
configuration_parameter. Its actually cool that it does, but this doc fix
should address this oversight as well.
On Thu, Feb 4, 2021 at 4:45 PM Masahiro Ikeda
wrote:
> I pgindented the patches.
>
>
... XLogWrite, which is invoked during an
XLogFlush request (see ...). This is also incremented
by the WAL receiver during replication.
("which normally called" should be "which is normally called" or "which
no
On Sun, Feb 7, 2021 at 11:39 AM Pavel Stehule
wrote:
>
>
> ne 7. 2. 2021 v 19:18 odesílatel Zhihong Yu napsal:
>
>> Hi,
>>
>> bq. SELECT unnest('[[5,2],"a",[8,[3,2],6]]'::jsonb);
>>
>> Since the array without cast is not normal array (and would be rejected),
>> I wonder if the cast is needed.
>>
On Sunday, February 7, 2021, Zhihong Yu wrote:
> Hi,
> # SELECT '[[5,2],"a",[8,[3,2],6]]'::jsonb;
> jsonb
> ---
> [[5, 2], "a", [8, [3, 2], 6]]
> (1 row)
>
> unnest(array[[3,2],"a",[1,4]]) is not accepted currently.
>
> Would the enhanced unnest accept th
On Mon, Jan 25, 2021 at 11:56 PM Masahiro Ikeda
wrote:
>
> > (wal_write)
> > The number of times WAL buffers were written out to disk via XLogWrite
> >
>
> Thanks.
>
> I thought it's better to omit "The" and "XLogWrite" because other views'
> description
> omits "The" and there is no description
On Mon, Jan 25, 2021 at 4:37 PM Masahiro Ikeda
wrote:
>
> I agree with your comments. I think it should report when
> reaching the end of WAL too. I add the code to report the stats
> when finishing the current WAL segment file when timeout in the
> main loop and when reaching the end of WAL.
>
>
On Mon, Jan 25, 2021 at 8:03 AM Masahiko Sawada
wrote:
> On Mon, Jan 25, 2021 at 4:51 PM Masahiro Ikeda
> wrote:
> >
> > Hi, thanks for the reviews.
> >
> > I updated the attached patch.
>
> Thank you for updating the patch!
>
Your original email with "total number of times" is more correct, re
On Fri, Jan 15, 2021 at 2:59 PM Robert Haas wrote:
> On Fri, Jan 15, 2021 at 4:47 PM Bruce Momjian wrote:
> > If people want changes, I need to hear about it here. I have address
> > everything people have mentioned in these threads so far.
>
> That does not match my perception of the situation
On Fri, Jan 15, 2021 at 12:28 AM Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
> On 2020-12-31 04:28, David Fetter wrote:
> > This could probably use a lot of filling in, but having it in the
> > actual documentation beats needing to know folklore even to know
> > that the capabilit
On Fri, Jan 15, 2021 at 12:16 AM Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
> On 2020-10-12 23:54, David G. Johnston wrote:
> > --- a/doc/src/sgml/backup.sgml
> > +++ b/doc/src/sgml/backup.sgml
> > @@ -722,6 +722,8 @@ test ! -f
> > /mnt/server/ar
On Wed, Jan 13, 2021 at 6:59 AM Ashutosh Bapat
wrote:
> +01 indicates that there's timezone information added to the data, so
> the rows aren't identical. Here's some more SQL run on my laptop which
> shows that
>
This is indeed true but examples that use the textual representation of the
data d
On Mon, Jan 4, 2021 at 8:26 AM Joel Jacobson wrote:
> In the documentation at
> https://www.postgresql.org/docs/current/functions-admin.html
> this behaviour is not mentioned anywhere as far as I can see:
>
>
https://www.postgresql.org/docs/current/runtime-config-custom.html
I do think "Customiz
On Mon, Dec 21, 2020 at 2:44 PM Bruce Momjian wrote:
> On Sun, Dec 20, 2020 at 09:38:55PM -0500, Stephen Frost wrote:
> > > I'll have a go at adding another keyring and/or abstracting the key
> > > wrap and see how well a true peer to the passphrase approach fits in.
> >
> > Having patches to rev
On Sun, Dec 20, 2020 at 11:07 AM Tom Lane wrote:
> If we could draw a line between "safe" and "unsafe" environment
> variables, I'd be willing to consider a patch that allows directly
> setting only the former. But I don't see how to draw that line.
>
>
IIUC the threat here is for users that wri
On Mon, Dec 14, 2020 at 1:40 PM Joshua Drake wrote:
> For example, what would be exceedly helpful would be a documentation style
>>> guide that is canonical and we can review documentation against.
>>>
>>
I do agree with that premise, with the goal of getting more people to
contribute to writing
On Mon, Dec 14, 2020 at 12:50 PM Joshua Drake wrote:
> -hackers,
>
> The community has spent a lot of time optimizing features over the years.
> Excellent examples include parallel query and partitioning which have been
> multi-year efforts to increase the quality, performance, and extend
> feat
On Sat, Dec 12, 2020 at 7:02 AM James Coleman wrote:
>
> Certainly almost every ORM, and maybe even other forms of application
> code, need to be able to associate the serial column value returned
> with what it inserted.
>
Yet most ORM would perform single inserts at a time, not in bulk, making
On Fri, Dec 11, 2020 at 6:24 AM Ashutosh Bapat
wrote:
> On Thu, Dec 10, 2020 at 7:49 PM David G. Johnston
> wrote:
>
> > Yeah, the ongoing work on parallel inserts would seem to be an issue.
> We should probably document that though. And maybe as part of parallel
> inserts
On Thursday, December 10, 2020, Ashutosh Bapat
wrote:
> On Wed, Dec 9, 2020 at 9:10 PM David G. Johnston
> wrote:
> >
> > Hey,
> >
> > Would it be accurate to add the following sentence to the INSERT
> documentation under "Outputs"?
> >
&g
Hey,
Would it be accurate to add the following sentence to the INSERT
documentation under "Outputs"?
"...inserted or updated by the command." For a multiple-values insertion,
the order of output rows will match the order that rows are presented in
the values or query clause.
https://www.postgre
On Fri, Dec 4, 2020 at 12:00 PM Stephen Frost wrote:
> Obviously, I'd then have to adjust the patch that I proposed for default
> roles, or move forward with it as-is, depending on what we end up doing
> here. I dislike what feels like a state of limbo for this right now
> though.
>
>
We have a
On Wed, Dec 2, 2020 at 5:26 PM Bruce Momjian wrote:
> I think the ideal solution is to create a section for all the rename
> cases and do all the redirects to that page. The page would list the
> old and new name for each item, and would link to the section for each
> new item.
>
>
Nothing preve
Hackers,
Given that we have already heard about 3 separate minor release regressions
in the most recent update I'm putting forth for discussion whether an
off-schedule release should be done. I probably wouldn't care as much if
it wasn't for the fact that the same release fixes two CVEs.
https:/
On Mon, Nov 30, 2020 at 1:15 PM Jürgen Purtz wrote:
> On 30.11.20 20:45, Anastasia Lubennikova wrote:
> > As far as I see something got committed and now the discussion is stuck
> in arguing about parenthesis.
> > FWIW, I think it is a matter of personal taste. Maybe we can compromise
> on simply
On Mon, Nov 30, 2020 at 11:42 AM Bruce Momjian wrote:
>
> The downside is you end up with X-1 dummy sections just to allow for
> references to old syntax, and you then have to find them all and remove
> them when you implement the proper solution. I have no intention of
> applying such an X-1 fi
On Mon, Nov 30, 2020 at 11:25 AM Bruce Momjian wrote:
> On Mon, Nov 30, 2020 at 10:11:04AM +0800, Craig Ringer wrote:
> > Can we please just address this docs issue? If you don't like my
> solution can
> > you please supply a patch that you feel addresses the problem? Or
> clearly state
> > that
On Mon, Nov 30, 2020 at 12:51 AM Pavel Stehule
wrote:
>
>
> po 30. 11. 2020 v 4:24 odesílatel David G. Johnston <
> david.g.johns...@gmail.com> napsal:
>
>> On Thu, Nov 26, 2020 at 12:49 AM Pavel Stehule
>> wrote:
>>
>>>
>>>
On Thu, Nov 26, 2020 at 12:49 AM Pavel Stehule
wrote:
>
>
> čt 26. 11. 2020 v 6:41 odesílatel David G. Johnston <
> david.g.johns...@gmail.com> napsal:
>
>> Hackers,
>>
>> Bug # 16519 [1] is another report of confusion regarding trying to use
>> pa
On Sat, Nov 28, 2020 at 4:18 PM Eugen Konkov wrote:
> Hi all.
>
> I often fall into error like this:
>
> DBIx::Class::Storage::DBI::_dbh_execute(): DBI Exception: DBD::Pg::st
> execute failed: ERROR: timestamp out of range
> CONTEXT: SQL function "accounting_ready" statement 1 [for Statement
>
On Wed, Nov 25, 2020 at 8:14 AM Konstantin Knizhnik <
k.knizh...@postgrespro.ru> wrote:
> Hi hackers,
>
> I wonder if it is considered as correct behavior that transaction
> conflict detection depends on presence of primary key:
>
> create table t(pk integer, val integer);
> insert into t values (
On Tue, Nov 24, 2020 at 8:45 AM Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> We're subject to whatever the kernel behavior is. If the kernel doesn't
> report address conflicts for Unix-domain sockets, then we can't do
> anything about that. Having an error message ready in case
On Mon, Nov 23, 2020 at 9:00 AM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> Or is it the case that we always attempt to bind the TCP/IP port,
> regardless of the presence of a socket file, in which case the failure for
> port binding does cover the socket situation a
On Mon, Nov 23, 2020 at 11:22 PM Li Japin wrote:
>
> How about use “foreign-data wrapper” replace “postgres_fdw”?
>
I don't see much value in avoiding mentioning that specific term - my
proposal turned it into an example instead of being exclusive.
> - This parameter should be set to z
On Mon, Nov 23, 2020 at 5:02 PM kuroda.hay...@fujitsu.com <
kuroda.hay...@fujitsu.com> wrote:
> No one have any comments, patch tester says OK, and I think this works
> well.
> I changed status to "Ready for Committer."
>
Some proof-reading:
v8-0001
Documentation:
My suggestion wasn't taken for
On Mon, Nov 23, 2020 at 6:50 AM Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 2020-11-20 18:23, David G. Johnston wrote:
> > If there is dead code there is an underlying problem to
> > address/discover, not just removing the dead code. In this case are we
On Friday, November 20, 2020, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 2020-11-18 04:35, David G. Johnston wrote:
>
>>
>>
>> I agree that there isn't a useful hint for the abstract case as it
>> shouldn't happen unless the
On Wednesday, November 18, 2020, Tom Lane wrote:
> I wrote:
> > So my vote would be to rip it out, not document it. Somebody can try
> > again in future, perhaps. But if we document it we're just locking
> > ourselves into a SQL incompatibility.
>
> Apparently, somebody already had that thought
Hackers,
Over in news [1] Josh Drake and Eric Ridge discovered the undocumented
feature "IS [NOT] OF"; introduced seemingly as an "oh-by-the-way" in 2002
via commit eb121ba2cfe [2].
Is there any reason not to document this back to 9.5, probably with a note
nearby to pg_typeof(any), which is a con
On Wed, Nov 18, 2020 at 5:54 PM Chapman Flack wrote:
> On 11/18/20 19:46, David G. Johnston wrote:
>
> > I doubt there is any substantial resistance to including such a function
> > but it would have to be written in C.
>
> Would anything have to be written at all, s
On Wed, Nov 18, 2020 at 5:37 PM Vik Fearing wrote:
> On 11/18/20 11:19 PM, David G. Johnston wrote:
> > On Wednesday, November 18, 2020, Vlad Bokov wrote:
> >
> >> Hi, I wonder why there's no function to aggregate arrays by
> >> concatenation out
On Wednesday, November 18, 2020, Vlad Bokov wrote:
> Hi, I wonder why there's no function to aggregate arrays by
> concatenation out of the box?
>
See array_agg(...)
David J.
On Tue, Nov 17, 2020 at 7:00 PM Michael Paquier wrote:
> On Tue, Nov 17, 2020 at 11:18:12PM +0100, Peter Eisentraut wrote:
> > So the mention of the "port" doesn't really add any information here and
> > just introduces new terminology that isn't really relevant.
> >
> > My idea is to change the
On Tue, Nov 17, 2020 at 6:13 AM Heikki Linnakangas wrote:
> On 02/11/2020 18:02, David G. Johnston wrote:
> > diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
> > index bf6004f321..43bc2cf086 100644
> > --- a/doc/src/sgml/func.sgml
> > +++ b/doc/src/sgm
On Monday, November 16, 2020, Li Japin wrote:
>
>
> Consider setting this for specific users instead of as a server default.
> Client connections managed by connection poolers, or initiated indirectly
> like those by a remote postgres_fdw using server, should probably be
> excluded from this tim
On Mon, Nov 16, 2020 at 5:41 AM Li Japin wrote:
> Thanks for your review! Attached.
>
Reading the doc changes:
I'd rather not name postgres_fdw explicitly, or at least not solely, as a
reason for setting this to zero. Additionally, using postgres_fdw within
the server doesn't cause issues, its
On Fri, Nov 13, 2020 at 5:38 PM Alvaro Herrera
wrote:
> Here's a v25.
>
> I made a few more changes to the docs per David's suggestions; I also
> reordered the sections quite a bit. It's now like this:
> * Batch Mode
>* Using Batch Mode
> * Issuing Queries
> * Processing Results
>
On Mon, Nov 16, 2020 at 1:52 PM Simon Riggs wrote:
> The docs are misleading for this feature, since they say:
> "This option disables all page-skipping behavior, and is
> intended to be used only when the contents of the visibility map are
> suspect, which should happen only if there is a hardwa
On Fri, Nov 13, 2020 at 10:42 AM Bruce Momjian wrote:
> I think the big problem, and I have seen this repeatedly, is showing up
> with a patch without discussing whether people actually want the
> feature. I know it is a doc issue, but our TODO list has the order as:
>
> Desirability ->
On Thursday, November 12, 2020, Bruce Momjian wrote:
> On Thu, Nov 12, 2020 at 01:52:11PM -0500, Tom Lane wrote:
> > On the whole, I'm on the side of the people who don't want to change
> this.
> > The implementation cost seems likely to greatly outweigh the value, plus
> > it feels more like a w
On Thu, Nov 12, 2020 at 9:32 AM Andrew Dunstan wrote:
>
> On 11/12/20 11:12 AM, David G. Johnston wrote:
> > On Thu, Nov 12, 2020 at 8:59 AM Andrew Dunstan > <mailto:and...@dunslane.net>> wrote:
> >
> >
> >
> > So if we then say:
On Thu, Nov 12, 2020 at 8:59 AM Andrew Dunstan wrote:
>
>
> So if we then say:
>
>
> select x, j->>x from mytable;
>
>
> you want both result columns named x? That seems like a recipe for
> serious confusion. I really don't think this proposal has been properly
> thought through.
>
>
IMO It n
On Thu, Nov 12, 2020 at 7:18 AM Eugen Konkov wrote:
> Hello Andrew,
>
> Thursday, November 12, 2020, 3:19:39 PM, you wrote:
>
>
> > On 11/11/20 7:55 PM, Bruce Momjian wrote:
>
> > select j->>x from mytable;
> > What should the column be named?
>
> Suppose it should be named 'as x'
>
+1
>
>
>
On Wed, Nov 11, 2020 at 7:54 PM Eugen Konkov wrote:
> Hello David,
>
> I have a table with services, each service have a period. After which
> service is auto renewal
>
> Services also could be one-time. At this case its interval is '00:00:00'
>
In which case the concept of interval is undefined
On Wed, Nov 11, 2020 at 5:56 PM Bruce Momjian wrote:
> On Thu, Nov 12, 2020 at 12:18:49AM +, Dagfinn Ilmari Mannsåker wrote:
> > Bruce Momjian writes:
> > > I think we could do it, but it would only work if the column was output
> > > as a single json value, and not a multi-key/value field.
On Wed, Nov 11, 2020 at 12:44 PM Bruce Momjian wrote:
> On Tue, Nov 10, 2020 at 01:38:14PM +0800, Craig Ringer wrote:
> > Hi all
> >
> > I noticed that when recovery.conf was removed in 2dedf4d9a8 (yay!) the
> docs for
> > it were removed completely as well. That's largely sensible, but is
> conf
On Wed, Nov 11, 2020 at 12:12 PM Eugen Konkov wrote:
>
> > So I feature request to allow zero size step for cases when
> start point is equest to finish
>
> > What do you think?
>
>
>
> hm probably with step 0 we always should generate series of one
> value and exit, despite on fin
On Wed, Nov 11, 2020 at 11:59 AM Eugen Konkov wrote:
> So I feature request to allow zero size step for cases when start
> point is equest to finish
>
> What do you think?
>
I don't see how this is useful. If they are equal and you use a non-zero
step you get back the one record you ar
On Wed, Nov 11, 2020 at 8:56 AM Bruce Momjian wrote:
> > It would be useful if the name of column will be autoassigned based on
> > name of json key. Like at next query:
> >
> > tucha=# select info->>'suma' as suma, docn from document order by id
> desc limit 5;
> > suma | docn
> > +--
On Sun, Nov 8, 2020 at 8:56 AM Jürgen Purtz wrote:
> Good catches. Everything applied.
>
MVCC Section
The first paragraph and example in the MVCC section is a good example but
seems misplaced - its relationship to MVCC generally is tenuous, rather I
would expect a discussion of the serializable
On Sun, Nov 8, 2020 at 8:56 AM Jürgen Purtz wrote:
>
> Good catches. Everything applied.
>
Reviewed the first three sections.
template0 - I would remove the schema portions of this and simply note this
as being a pristine recovery database in the diagram.
I would drop the word "more" and just
On Mon, Nov 9, 2020 at 10:36 AM Stephen Frost wrote:
> * David G. Johnston (david.g.johns...@gmail.com) wrote:
>
> > If the commit doesn't complete all of the newly created pages are junk.
> > Otherwise, you have a crash-recoverable state for those tables as regards
&
On Mon, Nov 9, 2020 at 8:18 AM Stephen Frost wrote:
> Presently, my feeling is that we could address this use-case without
>
having to introduce a new cluster-wide WAL level, and that's the
> direction I'd want to see this going. Perhaps I'm missing something
> about why the approach I've set fo
On Thu, Nov 5, 2020 at 3:43 PM Mohamed Wael Khobalatte <
mkhobala...@grubhub.com> wrote:
> You can always cast to text yourself, of course, but I am not familiar
> with the type hierarchy enough to tell why `to_json` can't deduce that as
> text whereas the other function can.
>
My understanding
On Mon, Nov 2, 2020 at 8:58 AM Alvaro Herrera
wrote:
> On 2020-Nov-02, Alvaro Herrera wrote:
>
> > In v23 I've gone over docs; discovered that PQgetResults docs were
> > missing the new values. Added those. No significant other changes yet.
>
>
Just reading the documentation of this patch, have
On Tue, Oct 27, 2020 at 1:19 AM Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 2020-10-13 00:43, David G. Johnston wrote:
> > Over in Bug# 16652 [1] Christoph failed to recognize the fact that
> > signal sending functions are inherently one-way just as signa
On Fri, Oct 30, 2020 at 9:16 AM Anastasia Lubennikova <
lubennikov...@gmail.com> wrote:
> Status update for a commitfest entry.
>
> It looks like there was no real progress on this issue since April. I see
> only an experimental patch. What kind of review does it need right now? Do
> we need more
On Wed, Oct 28, 2020 at 10:14 PM Bharath Rupireddy <
bharath.rupireddyforpostg...@gmail.com> wrote:
> On Wed, Oct 28, 2020 at 7:51 PM David G. Johnston
> wrote:
>
> > I was thinking this would be useful for orchestration. However, as you
> say, its a pretty fragile
On Wed, Oct 28, 2020 at 12:05 PM Tom Lane wrote:
> This doesn't seem clearly different from any other situation where
> auto-analyze doesn't react fast enough to suit you.
> I would not
> call it a bug, at least not without a wholesale redefinition of
> how auto-analyze is supposed to work.
On Mon, Oct 26, 2020 at 9:44 PM Nikolay Samokhvalov
wrote:
> On Mon, Oct 26, 2020 at 7:03 PM David G. Johnston <
> david.g.johns...@gmail.com> wrote:
>
>> On Monday, October 26, 2020, Nikolay Samokhvalov
>> wrote:
>>>
>>> Although, this trigger
On Wed, Oct 28, 2020 at 11:55 AM Tomas Vondra
wrote:
> I agree the lack of stats may be quite annoying and cause issues, but my
> guess is the chances of backpatching such change are about 0.01%. We
> have a usable 'workaround' for this - manual analyze.
>
My guess is that it wouldn't be too
On Wed, Oct 28, 2020 at 6:50 AM Bharath Rupireddy <
bharath.rupireddyforpostg...@gmail.com> wrote:
> Thanks for the comments.
>
> On Wed, Oct 28, 2020 at 6:41 PM Fujii Masao
> wrote:
> >
> > I prefer that false is returned when the timeout happens,
> > like pg_promote() does.
> >
>
> Earlier it w
On Monday, October 26, 2020, Nikolay Samokhvalov
wrote:
>
>
> Although, this triggers a question – should ANALYZE be automated in, say,
> pg_restore as well?
>
Independent concern.
>
> And another question: how ANALYZE needs to be run? If it's under the
> user's control, there is an option to u
On Mon, Oct 26, 2020 at 3:08 PM Fabrízio de Royes Mello <
fabriziome...@gmail.com> wrote:
> Hi all,
>
> As you all already know Postgres supports functions in index expressions
> (marked as immutable ofc) and for this special index the ANALYZE command
> creates some statistics (new pg_statistic en
Removing -docs as moderation won’t let me cross-post.
On Monday, October 26, 2020, David G. Johnston
wrote:
> On Monday, October 26, 2020, Jürgen Purtz wrote:
>
>> On 21.10.20 22:33, David G. Johnston wrote:
>>
>>
>> Two, I find the amount of detail being provided
On Fri, Oct 23, 2020 at 3:18 AM Jürgen Purtz wrote:
> and add a link to the "CREATE INDEX" command from the chapter preamble.
>
> is the link necessary?
>
I suppose it would make more sense to add it to the previous section - the
introduction page. I do think having a link (or more than one) to
On Wednesday, October 21, 2020, Bharath Rupireddy <
bharath.rupireddyforpostg...@gmail.com> wrote:
> Thanks for the feedback.
>
> On Wed, Oct 21, 2020 at 8:01 PM David G. Johnston
> wrote:
> >
> > On Wed, Oct 21, 2020 at 6:13 AM Magnus Hagander
> wrote:
>
On Wed, Oct 21, 2020 at 3:25 PM David G. Johnston <
david.g.johns...@gmail.com> wrote:
>
> v3-0002 needs a rebase over the create_index.sgml page due to the change
> of the nearby xref to link. Attached as v4-0002 along with the original
> v3-0001.
>
>
attached...
Readi
On Wed, Sep 30, 2020 at 2:10 AM Michael Paquier wrote:
> On Tue, Sep 08, 2020 at 01:25:21PM -0400, James Coleman wrote:
> > Álvaro's patch confused the current state of this thread, so I'm
> > reattaching (rebased) v2 as v3.
>
> +
> + CREATE INDEX (including the
> CONCURRENTLY
> + option) c
On Wed, Sep 30, 2020 at 4:25 AM Dagfinn Ilmari Mannsåker
wrote:
> Michael Paquier writes:
>
> > On Mon, Aug 10, 2020 at 12:52:17PM +, Jürgen Purtz wrote:
> >> The new status of this patch is: Waiting on Author
> >
> > This has not been answered yet, so I have marked the patch as returned
> >
Hackers,
Moving this over from -general [1]
David J.
[1]
https://www.postgresql.org/message-id/CAKFQuwaM1K%3DprJNwKnoaC2AyDFn-7OvtCpmQ23bcVe5Z%3DLKA3Q%40mail.gmail.com
diff --git a/doc/src/sgml/ref/create_table.sgml
b/doc/src/sgml/ref/create_table.sgml
index 087cad184c..a400334092 100644
--- a/
Hackers,
Bug # 16519 [1] is another report of confusion regarding trying to use
parameters in improper locations - specifically the SET ROLE command within
pl/pgsql. I'm re-attaching the doc patch and am adding it to the
commitfest.
David J.
[1]
https://www.postgresql.org/message-id/16519-9ef04
Hackers,
Over in -docs [1], where I attached the wrong patch anyway, the poster
needed some clarity regarding view updating. A minor documentation patch
is attached providing just that.
David J.
[1] https://www.postgresql.org/message-id/20200303174248.GB5019%40panix.com
v1-doc-rules-view-upda
801 - 900 of 1172 matches
Mail list logo
