On Wed, Dec 02, 2020 at 02:26:24PM +0100, Peter Eisentraut wrote:
> There are a number of elog(LOG) calls that appear to be user-facing, so they
> should be ereport()s.
> @@ -8591,25 +8604,46 @@ LogCheckpointEnd(bool restartpoint)
> CheckpointStats.ckpt_sync_rels;
>
On Wed, 2 Dec 2020 at 15:41, Michael Paquier wrote:
> On Tue, Dec 01, 2020 at 07:39:30PM +0800, Craig Ringer wrote:
> > On Wed, 14 Oct 2020, 13:06 Michael Paquier, wrote:
> >> Yeah, it is safer to assume that it is the responsability of the
> >> backup tool to ensure that because it could be
On Tue, 27 Oct 2020 at 16:34, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 2020-09-25 09:40, Craig Ringer wrote:
> > While working on extensions I've often wanted to enable cache clobbering
> > for a targeted piece of code, without paying the price of running it for
> > all
On Thu, Dec 3, 2020 at 2:29 PM Kyotaro Horiguchi
wrote:
> At Thu, 3 Dec 2020 12:27:53 +0900, Amit Langote
> wrote in
> > On Thu, Dec 3, 2020 at 10:15 AM Kyotaro Horiguchi
> > wrote:
> > > I don't think you're missing something. As I (tried to..) mentioned in
> > > another branch of this
On Thu, Dec 3, 2020 at 5:34 PM Masahiko Sawada wrote:
> While looking at the patch set I found that the tests in
> src/test/subscription don't work with this patch. I got the following
> error:
>
> 2020-12-03 15:18:12.666 JST [44771] tap_sub ERROR: unrecognized
> pgoutput option: two_phase
>
From: Jamison, Kirk/ジャミソン カーク
> Apologies for the delay, but attached are the updated versions to simplify the
> patches.
Looks good for me. Thanks to Horiguchi-san and Andres-san, the code bebecame
further compact and easier to read. I've marked this ready for committer.
To the committer:
On Wed, Dec 02, 2020 at 10:30:08PM -0600, Justin Pryzby wrote:
> Good idea. I think you mean like this.
Yes, something like that. Thanks.
> +typedef struct ReindexParams {
> + bool concurrently;
> + bool verbose;
> + bool missingok;
> +
> + int options;/* bitmask of
On Wed, Dec 02, 2020 at 11:04:45AM -0300, Alvaro Herrera wrote:
> Please take the opportunity to move the flag name out of the message in
> this one, also. I do wonder if it'd be a good idea to move the syscall
> name itself out of the message, too; that would reduce the number of
> messages to
On Thu, Dec 3, 2020 at 12:02 PM Josef Šimánek wrote:
> st 2. 12. 2020 v 23:36 odesílatel Andrew Dunstan napsal:
> > On 12/2/20 5:13 PM, Thomas Munro wrote:
> > > I'm experimenting with Github's built in CI. All other ideas welcome.
> >
> > I'd look very closely at gitlab.
>
> I was about to
On Mon, Nov 30, 2020 at 8:07 PM Alvaro Herrera
wrote:
> On 2020-Nov-30, Ashutosh Bapat wrote:
>
> > Peter Eisentraut explained that the translation system can not handle
> > strings broken by macros, e.g. errmsg("foo" MACRO "bar"), since it
> doesn't
> > know statically what the macro resolves
On Wed, Dec 2, 2020 at 8:24 PM Peter Smith wrote:
>
> I have rebased the v28 patch set (made necessary due to recent commit [1])
> [1]
> https://github.com/postgres/postgres/commit/0926e96c493443644ba8e96b5d96d013a9ffaf64
>
> And at the same time I have added patch 0009 to this set - This is for
Hi hackers,
I'm looking for more horsepower for testing commitfest entries
automatically, and today I tried out $SUBJECT. The attached is a
rudimentary first attempt, for show-and-tell. If you have a Github
account, you just have to push it to a branch there and look at the
Actions tab on the
On Mon, Nov 30, 2020 at 7:38 PM Li Japin wrote:
> Hi,
>
> On Nov 30, 2020, at 9:06 PM, Ashutosh Bapat
> wrote:
>
> On Fri, Nov 27, 2020 at 9:51 PM Li Japin wrote:
>
>
> Hi,
>
> Here, we cannot use sizeof(but) to get the buf size, because it is a
> pointer, so it always
> 8 bytes on 64-bit or 4
On Wed, Dec 2, 2020 at 10:24 PM Justin Pryzby wrote:
>
> One loose end in this patch is how to check for volatile default expressions.
>
> copyfrom.c is a utility statement, so it can look at the parser's column list:
> COPY table(c1,c2)...
>
> However, for INSERT, in nodeModifyTable.c, it looks
At Thu, 3 Dec 2020 12:27:53 +0900, Amit Langote wrote
in
> Hello,
>
> On Thu, Dec 3, 2020 at 10:15 AM Kyotaro Horiguchi
> wrote:
> > At Wed, 2 Dec 2020 22:02:50 +0900, Amit Langote
> > wrote in
> > > Hmm, I don't see what the problem is here, because it's not
> > > RI_ConstraintInfo that is
st 2. 12. 2020 v 21:02 odesílatel Tom Lane napsal:
> Dmitry Dolgov <9erthali...@gmail.com> writes:
> >> On Wed, Dec 02, 2020 at 12:58:51PM -0500, Tom Lane wrote:
> >> So ... one of the things that's been worrying me about this patch
> >> from day one is whether it would create a noticeable
Hi,
We are using Windows 2019 server.
Sometimes we see the pg_ctl.exe getting automatically deleted.
Due to this, while starting up Postgres windows service we are getting the
error.
"Error 2: The system cannot find the file specified"
Can you let us know the potential causes for this
On Thu, Dec 03, 2020 at 10:19:43AM +0900, Michael Paquier wrote:
> OK, this one is now committed. As of this thread, I think that we are
> going to need to do a bit more once we add options that are not just
> booleans for both commands (the grammar rules do not need to be
> changed now):
> -
On 2020/12/03 13:07, Tom Lane wrote:
Fujii Masao writes:
On 2020/12/03 1:04, Heikki Linnakangas wrote:
We never use non-default conversions for anything. All code that performs
encoding conversions only cares about the default ones.
Yes. I had to update pg_conversion.condefault
Fujii Masao writes:
> On 2020/12/03 1:04, Heikki Linnakangas wrote:
>> We never use non-default conversions for anything. All code that performs
>> encoding conversions only cares about the default ones.
> Yes. I had to update pg_conversion.condefault directly so that we can
> use custom
On 2020/12/03 1:04, Heikki Linnakangas wrote:
Hi,
PostgreSQL allows writing custom encoding conversion functions between any
character encodings, using the CREATE CONVERSION command. It's pretty flexible,
you can define default and non-default conversions, and the conversions live in
On 2020/12/03 11:48, tsunakawa.ta...@fujitsu.com wrote:
From: Michael Paquier
Tsunakawa-san, could you post a link to this article, if possible? I am curious
about their problem and why they used CREATE CONVERSION as a way to
solve it. That's fine even if it is in Japanese.
I just
Thanks for the review.
On Thu, Dec 3, 2020 at 7:24 AM Hou, Zhijie wrote:
>
> 1.
> +
> + ereport(WARNING,
> + (errmsg("could not wait for the termination of the
> backend with PID %d within %ld milliseconds",
> + pid, timeout)));
From: Osumi, Takamichi/大墨 昂道
> I've made a new patch v05 that took in comments to filter out WALs more
> strictly
> and addressed some minor fixes that were discussed within past few days.
> Also, I changed the documentations, considering those modifications.
The code looks
On Thursday, November 26, 2020 4:19 PM, Horiguchi-san wrote:
> Hello, Kirk. Thank you for the new version.
Apologies for the delay, but attached are the updated versions to simplify the
patches.
The changes reflected most of your comments/suggestions.
Summary of changes in the latest versions.
>
> I changed the status to 'wait on anthor'.
> The others of the patch LGTM,
> I think it can be changed to Ready for Committer again, when this comment
> is confirmed.
>
I am Sorry I forgot a possible typo comment.
+{ oid => '16386', descr => 'terminate a backend process and wait for it\'s
Hello,
On Thu, Dec 3, 2020 at 10:15 AM Kyotaro Horiguchi
wrote:
> At Wed, 2 Dec 2020 22:02:50 +0900, Amit Langote
> wrote in
> > Hello,
> >
> > On Tue, Dec 1, 2020 at 9:40 AM Kyotaro Horiguchi
> > wrote:
> > >
> > > At Mon, 30 Nov 2020 21:03:45 -0300, Alvaro Herrera
> > > wrote in
> > > >
Hello
I've made a new patch v05 that took in comments
to filter out WALs more strictly and addressed some minor fixes
that were discussed within past few days.
Also, I changed the documentations, considering those modifications.
Best,
Takamichi Osumi
disable_WAL_logging_v05.patch
From: Michael Paquier
> Tsunakawa-san, could you post a link to this article, if possible? I am
> curious
> about their problem and why they used CREATE CONVERSION as a way to
> solve it. That's fine even if it is in Japanese.
I just pulled info from my old memory in my previous mail. Now
On Wed, Dec 2, 2020 at 7:11 PM Masahiko Sawada wrote:
>
> On Wed, Dec 2, 2020 at 3:33 PM Fujii Masao
> wrote:
> >
> >
> >
> > On 2020/12/02 12:53, Masahiko Sawada wrote:
> > > On Tue, Dec 1, 2020 at 5:31 PM Masahiko Sawada
> > > wrote:
> > >>
> > >> On Tue, Dec 1, 2020 at 4:32 PM Fujii Masao
On 12/02/20 16:51, David Steele wrote:
> Depending on how you have Github organized migrating to travis-ci.com may be
> bit tricky because it requires full access to all private repositories in
> your account and orgs administrated by your account.
PL/Java just began using travis-ci.com this
> I recall a discussion in which someone explained that things are messy for
> Japanese because there's not really just one version of SJIS; there are
> several, because various groups extended the original standard in not-
> quite-compatible ways. In turn this means that there's not really one
>
> > + ereport(WARNING,
> > + (errmsg("could not wait for the termination of the
> backend with PID %d within %ld milliseconds",
> > + pid, timeout)));
>
> > The code use %ld to print int64 type.
> > How about use INT64_FORMAT, which looks more
Hi all,
Now that the tree has a new set of files for cryptohash functions as
of src/common/cryptohash*.c, it is a bit weird to have another file
called cryptohashes.c for the set of SQL functions.
Any objections to rename that to cryptohashfuncs.c? That would be
much more consistent with the
"Hou, Zhijie" writes:
> + ereport(WARNING,
> + (errmsg("could not wait for the termination of the
> backend with PID %d within %ld milliseconds",
> + pid, timeout)));
> The code use %ld to print int64 type.
> How about use
Hi
I take a look into the patch, and here some comments.
1.
+
+ ereport(WARNING,
+ (errmsg("could not wait for the termination of the
backend with PID %d within %ld milliseconds",
+ pid, timeout)));
+
The code use %ld to print
On Thu, Dec 03, 2020 at 12:54:56AM +, tsunakawa.ta...@fujitsu.com wrote:
> I can't answer deeper questions because I'm not familiar with
> character sets, but I saw some Japanese web articles that use CREATE
> CONVERSION to handle external characters. So, I think we may as
> well retain it.
On Wed, Dec 02, 2020 at 12:03:49PM +0900, Michael Paquier wrote:
> Thanks. 0001 has been applied and the buildfarm does not complain, so
> it looks like we are good (I'll take care of any issues, like the one
> Fujii-san has just reported). Attached are new patches for 0002, the
> EVP switch.
"tsunakawa.ta...@fujitsu.com" writes:
> From: Heikki Linnakangas
>> Any objections? Anyone using custom encoding conversions in production?
> I can't answer deeper questions because I'm not familiar with character sets,
> but I saw some Japanese web articles that use CREATE CONVERSION to
Fujii Masao writes:
> I'm starting to study how this feature behaves. At first, when I executed
> the following query, the function never returned. ISTM that since
> the autovacuum launcher cannot respond to the request of memory
> contexts dump, the function keeps waiting infinity. Is this a
Hi Hackers,
>> I would embed all this knowledge in ri_BuildQueryKey though, without
>> adding the new function ri_GetParentConstOid. I don't think that
>> function meaningful abstraction value, and instead it would make what I
>> suggest more difficult.
> It seems to me reasonable.
Indeed, I
On Tue, Dec 01, 2020 at 03:10:13PM +0900, Michael Paquier wrote:
> Well, my impression is that both of you kept exchanging patches,
> touching and reviewing each other's patch (note that Alexei has also
> sent a rebase of 0002 just yesterday), so I think that it is fair to
> say that both of you
At Wed, 2 Dec 2020 22:02:50 +0900, Amit Langote wrote
in
> Hello,
>
> On Tue, Dec 1, 2020 at 9:40 AM Kyotaro Horiguchi
> wrote:
> >
> > At Mon, 30 Nov 2020 21:03:45 -0300, Alvaro Herrera
> > wrote in
> > > On 2020-Nov-26, Kyotaro Horiguchi wrote:
> > >
> > > > This shares RI_ConstraintInfo
On Wed, Dec 2, 2020 at 08:07:47PM -0500, Isaac Morland wrote:
> On Wed, 2 Dec 2020 at 19:33, David G. Johnston
> wrote:
>
> 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
On 2020/11/16 19:58, torikoshia wrote:
On 2020-10-28 15:32, torikoshia wrote:
On 2020-10-23 13:46, Kyotaro Horiguchi wrote:
I think we might need to step-back to basic design of this feature
since this patch seems to have unhandled corner cases that are
difficult to find.
I've written
On Wed, 2 Dec 2020 at 19:33, David G. Johnston
wrote:
> 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
On Wed, Dec 02, 2020 at 06:23:54AM -0800, Nikolay Samokhvalov wrote:
> On Tue, Dec 1, 2020 at 10:32 PM Julien Rouhaud wrote:
>
> > On Tue, Dec 01, 2020 at 10:08:06PM -0800, Nikolay Samokhvalov wrote:
> > > If all top-level records in pg_stat_statements have "true" in the new
> > > column
From: Heikki Linnakangas
> I propose that we add a notice to the CREATE CONVERSION docs to say that
> it is deprecated, and remove it in a few years.
>
> Any objections? Anyone using custom encoding conversions in production?
I can't answer deeper questions because I'm not familiar with
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
On Wed, Dec 2, 2020 at 05:57:01PM -0500, Stephen Frost wrote:
> * Bruce Momjian (br...@momjian.us) wrote:
> > We were not going to use just redirects --- we were going to create a
> > page that had all the renames listed, with links to the new names.
>
> Maybe I'm the one who is confused here,
On Wed, Dec 02, 2020 at 03:35:46PM -0500, Tom Lane wrote:
> Yeah, if we want to kill it let's just do so. The negative language in
> the reference page has been there since (at least) 7.1, so people can
> hardly say they didn't see it coming.
+1. I got to wonder about the impact when migrating
st 2. 12. 2020 v 23:36 odesílatel Andrew Dunstan napsal:
>
>
> On 12/2/20 5:13 PM, Thomas Munro wrote:
> >
> > I'm experimenting with Github's built in CI. All other ideas welcome.
>
>
>
> I'd look very closely at gitlab.
I was about to respond before with the same idea. Feel free to ping
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Wed, Dec 2, 2020 at 02:47:13PM -0500, Stephen Frost wrote:
> > * David G. Johnston (david.g.johns...@gmail.com) wrote:
> > > On Mon, Nov 30, 2020 at 11:42 AM Bruce Momjian wrote:
> > > > The downside is you end up with X-1 dummy sections
On Wed, Nov 25, 2020 at 06:35:19PM -0500, Tom Lane wrote:
> Justin Pryzby writes:
> > 1. Maybe pg_restore ExecuteSqlCommandBuf() should (always?) call
> > ExecuteSimpleCommands() instead of ExecuteSqlCommand(). It doesn't seem to
> > break anything (although that surprised me).
>
> That
On 12/2/20 5:13 PM, Thomas Munro wrote:
>
> I'm experimenting with Github's built in CI. All other ideas welcome.
I'd look very closely at gitlab.
cheers
andrew
On 12/2/20 5:13 PM, Thomas Munro wrote:
On Thu, Dec 3, 2020 at 10:51 AM David Steele wrote:
On 12/2/20 4:15 PM, Thomas Munro wrote:
On Thu, Dec 3, 2020 at 10:00 AM Tom Lane wrote:
This is actually a bit problematic, because now the cfbot is ignoring
those patches (or if it's not, I don't
On Thu, Dec 3, 2020 at 10:51 AM David Steele wrote:
> On 12/2/20 4:15 PM, Thomas Munro wrote:
> > On Thu, Dec 3, 2020 at 10:00 AM Tom Lane wrote:
> >> This is actually a bit problematic, because now the cfbot is ignoring
> >> those patches (or if it's not, I don't know where it's displaying the
On 12/2/20 4:15 PM, Thomas Munro wrote:
On Thu, Dec 3, 2020 at 10:00 AM Tom Lane wrote:
This is actually a bit problematic, because now the cfbot is ignoring
those patches (or if it's not, I don't know where it's displaying the
results). Please go ahead and move the remaining open patches, or
Attached is a patch for key management, which will eventually be part of
cluster file encryption (CFE), called TDE (Transparent Data Encryption)
by Oracle. It is an update of Masahiko Sawada's patch from July 31:
On Thu, Nov 26, 2020 at 8:15 AM Daniil Zakhlystov
wrote:
> However, I don’t mean by this that we shouldn’t support switchable
> compression. I propose that we can offer two compression modes: permanent
> (which is implemented in the current state of the patch) and switchable
> on-the-fly.
On Thu, Dec 3, 2020 at 10:00 AM Tom Lane wrote:
> This is actually a bit problematic, because now the cfbot is ignoring
> those patches (or if it's not, I don't know where it's displaying the
> results). Please go ahead and move the remaining open patches, or
> else re-open the CF if that's
Anastasia Lubennikova writes:
> Commitfest 2020-11 is officially closed now.
> Many thanks to everyone who participated by posting patches, reviewing
> them, committing and sharing ideas in discussions!
Thanks for all the hard work!
> Today, me and Georgios will move the remaining items to the
Stephen Frost writes:
> * Peter Eisentraut (peter.eisentr...@enterprisedb.com) wrote:
>> While reading about deprecating and removing various things in other
>> threads, I was wondering about how deprecated SELECT INTO is. There are
>> various source code comments about this, but the SELECT INTO
On Wed, Dec 2, 2020 at 02:47:13PM -0500, Stephen Frost wrote:
> Greetings,
>
> * David G. Johnston (david.g.johns...@gmail.com) wrote:
> > 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
On Tue, Dec 1, 2020 at 10:16:31AM -0800, Jeff Davis wrote:
> On Thu, 2020-10-08 at 23:17 -0400, Bruce Momjian wrote:
> > As I said before, it is more raw bytes, but
> > we
> > don't have an SQL data type for that.
>
> Sorry to jump in to this thread late.
>
> Can't we just set both "filename"
Hello David,
Some feedback about v4.
It looks that the option is *silently* ignored when creating a partitionned
table, which currently results in an error, and not passed to partitions,
which would accept them. This is pretty weird.
The input check is added with an error message when both
Dmitry Dolgov <9erthali...@gmail.com> writes:
>> On Wed, Dec 02, 2020 at 12:58:51PM -0500, Tom Lane wrote:
>> So ... one of the things that's been worrying me about this patch
>> from day one is whether it would create a noticeable performance
>> penalty for existing use-cases. I did a small
On Wed, Dec 02, 2020 at 12:58:36PM -0500, Stephen Frost wrote:
> Greetings,
>
> * Peter Eisentraut (peter.eisentr...@enterprisedb.com) wrote:
> > While reading about deprecating and removing various things in
> > other threads, I was wondering about how deprecated SELECT INTO
> > is. There are
"David G. Johnston" writes:
> 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
On Tue, Dec 1, 2020 at 08:19:34PM +0530, Abhijit Menon-Sen wrote:
> I'm certainly not in favour of introducing multiple operators to express
> the various list operations, like += for prepend and =+ for append. (By
> the standard of assembling such things from spare parts, the right thing
> to do
Greetings,
* David G. Johnston (david.g.johns...@gmail.com) wrote:
> 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
Greetings,
* Stephen Frost (sfr...@snowman.net) wrote:
> * vignesh C (vignes...@gmail.com) wrote:
> > Thanks for testing this, I had missed testing this. The expression
> > matching was not correct. Attached v6 patch which includes the fix for
> > this.
>
> This generally looks pretty good to
> On Wed, Dec 02, 2020 at 01:20:10PM -0600, Justin Pryzby wrote:
> On Wed, Dec 02, 2020 at 08:18:08PM +0100, Dmitry Dolgov wrote:
> > > On Wed, Dec 02, 2020 at 12:58:51PM -0500, Tom Lane wrote:
> > > So ... one of the things that's been worrying me about this patch
> > > from day one is whether it
On Wed, Dec 2, 2020 at 07:30:39PM +0100, Pavel Stehule wrote:
> postgres=# select
> 'Arabic : ' || unistr( '\0627\0644\0639\0631\0628\064A\0629' ) || '
> Chinese : ' || unistr( '\4E2D\6587' ) || '
> English : ' || unistr( 'English' )
On Wed, Dec 02, 2020 at 08:18:08PM +0100, Dmitry Dolgov wrote:
> > On Wed, Dec 02, 2020 at 12:58:51PM -0500, Tom Lane wrote:
> > So ... one of the things that's been worrying me about this patch
> > from day one is whether it would create a noticeable performance
> > penalty for existing
> On Wed, Dec 02, 2020 at 11:52:54AM -0500, Tom Lane wrote:
> Dmitry Dolgov <9erthali...@gmail.com> writes:
> >> On Mon, Nov 30, 2020 at 02:26:19PM +0100, Dmitry Dolgov wrote:
> >>> On Mon, Nov 30, 2020 at 04:12:29PM +0300, Alexander Korotkov wrote:
> >>> The idea of an opaque field in
> On Wed, Dec 02, 2020 at 12:58:51PM -0500, Tom Lane wrote:
> So ... one of the things that's been worrying me about this patch
> from day one is whether it would create a noticeable performance
> penalty for existing use-cases. I did a small amount of experimentation
> about that with the v35
st 2. 12. 2020 v 11:37 odesílatel Pavel Stehule
napsal:
>
>
> st 2. 12. 2020 v 9:23 odesílatel Peter Eisentraut <
> peter.eisentr...@enterprisedb.com> napsal:
>
>> On 2020-11-30 22:15, Pavel Stehule wrote:
>> > I would like some supporting documentation on this. So far we only
>> > have
Heikki Linnakangas writes:
> On 02/12/2020 18:18, Tom Lane wrote:
>> Heikki Linnakangas writes:
>>> I propose that we add a notice to the CREATE CONVERSION docs to say that
>>> it is deprecated, and remove it in a few years.
>> While I agree that it's probably not that useful, what would we
So ... one of the things that's been worrying me about this patch
from day one is whether it would create a noticeable performance
penalty for existing use-cases. I did a small amount of experimentation
about that with the v35 patchset, and it didn't take long at all to
find that this:
--- cut
Greetings,
* Peter Eisentraut (peter.eisentr...@enterprisedb.com) wrote:
> While reading about deprecating and removing various things in other
> threads, I was wondering about how deprecated SELECT INTO is. There are
> various source code comments about this, but the SELECT INTO reference page
One loose end in this patch is how to check for volatile default expressions.
copyfrom.c is a utility statement, so it can look at the parser's column list:
COPY table(c1,c2)...
However, for INSERT, in nodeModifyTable.c, it looks like parsing, rewriting,
and planning are done, at which point I
Dmitry Dolgov <9erthali...@gmail.com> writes:
>> On Mon, Nov 30, 2020 at 02:26:19PM +0100, Dmitry Dolgov wrote:
>>> On Mon, Nov 30, 2020 at 04:12:29PM +0300, Alexander Korotkov wrote:
>>> The idea of an opaque field in SubscriptingRef structure is more
>>> attractive to me. Could you please
On 12/2/20 4:51 PM, Dean Rasheed wrote:
> On Sun, 29 Nov 2020 at 21:02, Tomas Vondra
> wrote:
>>
>> I wonder how much of the comment before clauselist_selectivity should
>> move to clauselist_selectivity_ext - it does talk about range clauses
>> and so on, but clauselist_selectivity does not
On 12/02/20 09:55, Chapman Flack wrote:
> In Perl, there is a useful extension to regexp substitution where
> you specify the replacement not as a string or even a string with &
> and \1 \2 ... magic, but as essentially a lambda that is passed the
> match and returns a computed replacement. That
On 02/12/2020 18:18, Tom Lane wrote:
Heikki Linnakangas writes:
I propose that we add a notice to the CREATE CONVERSION docs to say that
it is deprecated, and remove it in a few years.
While I agree that it's probably not that useful, what would we gain
by removing it? If you intend to
Heikki Linnakangas writes:
> I propose that we add a notice to the CREATE CONVERSION docs to say that
> it is deprecated, and remove it in a few years.
While I agree that it's probably not that useful, what would we gain
by removing it? If you intend to remove those catalogs, what lookup
st 2. 12. 2020 v 12:55 odesílatel Peter Eisentraut <
peter.eisentr...@enterprisedb.com> napsal:
> While reading about deprecating and removing various things in other
> threads, I was wondering about how deprecated SELECT INTO is. There are
> various source code comments about this, but the
Hi,
PostgreSQL allows writing custom encoding conversion functions between
any character encodings, using the CREATE CONVERSION command. It's
pretty flexible, you can define default and non-default conversions, and
the conversions live in schemas so you can have multiple conversions
On Sun, 29 Nov 2020 at 21:02, Tomas Vondra
wrote:
>
> I wonder how much of the comment before clauselist_selectivity should
> move to clauselist_selectivity_ext - it does talk about range clauses
> and so on, but clauselist_selectivity does not really deal with that.
> But maybe that's just an
> On Mon, Nov 30, 2020 at 02:26:19PM +0100, Dmitry Dolgov wrote:
> > On Mon, Nov 30, 2020 at 04:12:29PM +0300, Alexander Korotkov wrote:
> >
> > > > My first question is whether we're
> > > > able to handle different subscript types differently. For instance,
> > > > one day we could handle
On 12/02/20 05:37, Pavel Stehule wrote:
> 2. there can be optional parameter "prefix" with default "\". But with "\u"
> it can be compatible with Java or Python.
Java's unicode escape form is one of those early ones that lack
a six-digit form, and where any character outside of the basic
On 02/12/2020 20:13, Heikki Linnakangas wrote:
On 01/12/2020 16:52, Pavel Borisov wrote:
Status update for a commitfest entry.
The patch is Waiting on Author for some time. As this is a bug fix,
I am
moving it to the next CF.
Ian, are you planning to continue working on it?
Previous discussions on macOS SIP:
https://www.postgresql.org/message-id/flat/561E73AB.8060800%40gmx.net
https://www.postgresql.org/message-id/flat/CA%2BTgmoYGi5oR8Rvb2-SY1_WEjd76H5gCqSukxFQ66qR7MewWAQ%40mail.gmail.com
On Tue, Dec 1, 2020 at 10:32 PM Julien Rouhaud wrote:
> On Tue, Dec 01, 2020 at 10:08:06PM -0800, Nikolay Samokhvalov wrote:
> > If all top-level records in pg_stat_statements have "true" in the new
> > column (is_toplevel), how would this lead to the need to increase
> > pg_stat_statements.max?
Hello
> - add a parent_statement_id column that would be NULL for top level queries
Will generate too much entries... Every FK for each different delete/insert,
for example.
But very useful for databases with a lot of stored procedures to find where
this query is called. May be new mode track
Hello Alvaro,
Thank you for your comments.
>
> > In second thought about the reason for the "toprel_oid". It is perhaps
> > to avoid "wrongly" propagated values to ancestors after a manual
> > ANALYZE on a partitioned table. But the same happens after an
> > autoanalyze iteration if some of the
On 2020-Dec-02, Peter Eisentraut wrote:
> There are a number of elog(LOG) calls that appear to be user-facing, so they
> should be ereport()s. This patch changes them. There are more elog(LOG)
> calls remaining, but they all appear to be some kind of debugging support.
> Also, I changed a few
On 2020-Dec-02, Erik Rijkers wrote:
> Hi
>
> I just noticed that in
>
> https://www.postgresql.org/docs/13/acronyms.html
> (i.e., doc/src/sgml/acronyms.sgml)
>
> there is under lemma 'HOT' a link with URL:
>
>
On Wed, Dec 2, 2020 at 1:30 PM Bharath Rupireddy <
bharath.rupireddyforpostg...@gmail.com> wrote:
> On Mon, Nov 30, 2020 at 8:10 PM Muhammad Usama wrote:
> >
> > The following review has been posted through the commitfest application:
> > make installcheck-world: tested, passed
> > Implements
1 - 100 of 125 matches
Mail list logo
