Hi
čt 13. 6. 2024 v 20:56 odesílatel Daniel Gustafsson
napsal:
> > On 13 Jun 2024, at 19:21, Pavel Stehule wrote:
>
> > Is the message "SQL expression ..." for RAW_PLPGSQL_EXPR correct?
>
> That indeed seems incorrect.
>
> > Should there be a "PL/pgSQL expression" instead?
>
> I think that wou
On Tue, 4 Jun 2024 at 10:21, Peter Smith wrote:
>
> Hi,
>
> Here are some review comments for patch v5-0002.
>
> ==
> GENERAL
>
> G1.
> IIUC now you are unconditionally allowing all generated columns to be copied.
>
> I think this is assuming that the table sync code (in the next patch
> 0003?
On Tue, 4 Jun 2024 at 15:01, Peter Smith wrote:
>
> Hi,
>
> Here are some review comments for patch v5-0003.
>
> ==
> 0. Whitespace warnings when the patch was applied.
>
> [postgres@CentOS7-x64 oss_postgres_misc]$ git apply
> ../patches_misc/v5-0003-Support-copy-of-generated-columns-during-ta
On Wed, 5 Jun 2024 at 05:49, Peter Smith wrote:
>
> On Mon, Jun 3, 2024 at 9:52 PM Shlok Kyal wrote:
> >
> > >
> > > The attached Patch contains the suggested changes.
> > >
> >
> > Hi,
> >
> > Currently, COPY command does not work for generated columns and
> > therefore, COPY of generated column
On Thu, 6 Jun 2024 at 08:29, Hayato Kuroda (Fujitsu)
wrote:
>
> Dear Shlok and Shubham,
>
> Thanks for updating the patch!
>
> I briefly checked the v5-0002. IIUC, your patch allows to copy generated
> columns unconditionally. I think the behavior affects many people so that it
> is
> hard to get
On Thu, Jun 13, 2024 at 9:22 PM Masahiko Sawada wrote:
> On Fri, Jun 14, 2024 at 9:57 AM Masahiko Sawada wrote:
> > On Fri, Jun 14, 2024 at 9:41 AM Michael Paquier wrote:
> > > On Thu, Jun 13, 2024 at 08:38:05PM -0400, Tom Lane wrote:
> > > > Masahiko Sawada writes:
> > > >> I was about to push
Hi,
Sorry, I have missed this in the original patch. I am surprised how that
happened. But thanks for catching the same and fixing it.
The changes are straightforward and look good to me. However, I have kept
the existing test of an empty array as is, assuming that it is one of the
valid tests. I
On Jun 15, 2024, at 10:27, Jeevan Chalke wrote:
> Sorry, I have missed this in the original patch. I am surprised how that
> happened. But thanks for catching the same and fixing it.
No worries. :-)
> The changes are straightforward and look good to me. However, I have kept the
> existing tes
On 2024-06-14 Fr 18:11, Jelte Fennema-Nio wrote:
On Fri, 14 Jun 2024 at 17:49, Tom Lane wrote:
But what I'd really like to see is some comparison of the
language-provided testing facilities that we're proposing
to depend on. Why is pytest (or whatever) better than Test::More?
Some advantage
On Jun 14, 2024, at 22:29, Chapman Flack wrote:
> So I should go look at our code to see what grammar we've implemented,
> exactly. It is beginning to seem as if we have simply added
> as another choice for an expression, not restricted
> to only appearing in a filter. If so, and we add document
On Jun 15, 2024, at 10:39, David E. Wheeler wrote:
>> The changes are straightforward and look good to me. However, I have kept
>> the existing test of an empty array as is, assuming that it is one of the
>> valid tests. It now returns zero rows instead of an error. Your added test
>> case cov
On 06/15/24 10:47, David E. Wheeler wrote:
> these are predicate check expressions, supported and documented
> as an extension to the standard since Postgres 12[1].
> ...
> [1]:
> https://www.postgresql.org/docs/devel/functions-json.html#FUNCTIONS-SQLJSON-CHECK-EXPRESSIONS
I see. Yes, that docume
On Sat, 15 Jun 2024 at 16:45, Andrew Dunstan wrote:
> I see the fact that we stash the output in a file as a feature. Without
> it, capturing failure information in the buildfarm client would be more
> difficult, especially if there are multiple failures. So this is
> actually something I think we
On 2024-06-15 Sa 10:51, David E. Wheeler wrote:
On Jun 15, 2024, at 10:39, David E. Wheeler wrote:
The changes are straightforward and look good to me. However, I have kept the
existing test of an empty array as is, assuming that it is one of the valid
tests. It now returns zero rows inste
On Sat, Jun 15, 2024 at 12:48 PM Jelte Fennema-Nio wrote:
> Honestly, my primary *objective* complaint about our current test
> suite, is that when a test fails, it's very often impossible for me to
> understand why the test failed, by only looking at the output of
> "meson test". I think logging
Hi,
On 2024-06-15 10:45:16 -0400, Andrew Dunstan wrote:
> > 4. Pytest has autodiscovery of test files and functions, so we
> > probably wouldn't have to specify all of the exact test files anymore
> > in the meson.build files.
>
>
> I find this comment a bit ironic. We don't need to do that with
On Sat, 15 Jun 2024 at 19:27, Robert Haas wrote:
> This surprises me. I agree that the current state of affairs is kind
> of annoying, but the contents of regress_log_whatever are usually
> quite long. Printing all of that out to standard output seems like
> it's just going to flood the terminal w
I wrote:
> The semantics I've implemented on top of that are:
> * ALTER OWNER does not touch pg_init_privs entries.
> * REASSIGN OWNED replaces pg_init_privs references with the new
> role, whether the references are as grantor or grantee.
> * DROP OWNED removes pg_init_privs mentions of the doomed
On 28.05.2024 07:05, Alexander Pyhalov wrote:
Ilya Gladyshev писал(а) 2024-05-28 02:52:
Also I'd like to note that in new patch version there's a strange
wording in documentation:
"This can be very convenient as not only will all existing
partitions be
indexed, but any future partitions w
On Thu, May 23, 2024 at 10:14:57PM +0100, Ilya Gladyshev wrote:
> Hi,
>
> I think it's well worth the effort to revive the patch, so I rebased it on
> master, updated it and will return it back to the commitfest. Alexander,
> Justin feel free to add yourselves as authors
Thanks -- I was intending
On Jun 15, 2024, at 12:48, Andrew Dunstan wrote:
> Not really needed, I will commit shortly.
Ah, okay, I wasn’t sure so just defaulted to making sure it was tracked. :-)
Thanks Andrew,
D
Hi,
In
"Re: Columnar format export in Postgres" on Thu, 13 Jun 2024 22:30:24 +0530,
Sushrut Shivaswamy wrote:
> - To facilitate efficient querying it would help to export multiple
> parquet files for the table instead of a single file.
>Having multiple files allows queries to skip chun
On Sat, Jun 15, 2024 at 12:48 PM Jelte Fennema-Nio
wrote:
> Afaict, there's a significant part of our current community who feel the
> same way (and I'm pretty sure every sub-30 year old person who
> newly joins the community would feel the exact same way too).
>
Those young-uns are also the sam
On Fri, Jun 14, 2024 at 5:09 PM Jelte Fennema-Nio
wrote:
> Test::More on the other hand, while indeed still maintained, it's
> definitely not getting significant new feature development or
> improvements[2]. Especially when comparing it to pytest[3].
>
That's fair, although it's a little hard to
On Sat, Jun 15, 2024 at 5:53 PM Greg Sabino Mullane wrote:
>
> On Sat, Jun 15, 2024 at 12:48 PM Jelte Fennema-Nio wrote:
>>
>> Afaict, there's a significant part of our current community who feel the
>> same way (and I'm pretty sure every sub-30 year old person who
>> newly joins the community w
On Wed, May 22, 2024 at 05:05:48PM -0700, Noah Misch wrote:
> https://postgr.es/m/20240512232923.aa.nmi...@google.com wrote:
> > Separable, nontrivial things not fixed in the attached patch stack:
> >
> > - Inplace update uses transactional CacheInvalidateHeapTuple(). ROLLBACK of
> > CREATE IND
Hi Team,
Greetings of the day!!
We are planning to partition tables using pg_partman. Like we are planning
for their backup and restoration process.
Got a few URLs where pg_dump had issues while restoring some data that was
lost.
kindly guide me the process or steps I need to follow for backing
Separating this from the pytest thread:
On Sat, Jun 15, 2024 at 01:26:57PM -0400, Robert Haas wrote:
> The one
> thing I know about that *I* think is a pretty big problem about Perl
> is that IPC::Run is not really maintained.
I don't see in https://github.com/cpan-authors/IPC-Run/issues anything
On Thu, Jun 13, 2024 at 07:42:25PM -0700, Noah Misch wrote:
> On Fri, Jun 14, 2024 at 09:58:59AM +0900, Michael Paquier wrote:
>> GetWaitEventCustomIdentifier() is incorrect, and should return
>> "InjectionPoint" in the default case of this class name, no?
>
> I intentionally didn't provide a defa
While my colleague is working on translating
doc/src/sgml/ref/create_role.sgml into Japanese, he has found
following sentence is hard to parse:
The rules for which initial
role membership options are enabled described below in the
IN ROLE, ROLE, and
ADMIN clauses.
Maybe we need "are"
On Sat, Jun 15, 2024 at 7:25 PM Tatsuo Ishii wrote:
>The rules for which initial
>role membership options are enabled described below in the
>IN ROLE, ROLE, and
>ADMIN clauses.
>
> Maybe we need "are" in front of "described"?
>
>
Agreed.
David J.
31 matches
Mail list logo
