On Fri, 18 Aug 2023 at 16:29, Juan José Santamaría Flecha
wrote:
>
>
> On Thu, Aug 17, 2023 at 3:51 PM Frédéric Yhuel
> wrote:
>>
>> On 8/17/23 14:00, Frédéric Yhuel wrote:
>> > On 8/17/23 09:32, Frédéric Yhuel wrote:
>> >> On 8/10/23 17:06, Juan José Santamaría Flecha wrote:
>> >>> Recently I
On Fri, 30 Jun 2023 at 07:43, Thomas Munro wrote:
>
> On Fri, Jun 30, 2023 at 3:39 AM Andres Freund wrote:
> > I am wondering if we don't want something more generic than stashing this in
> > rd_amcache. Don't want to end up duplicating relevant code across the uses
> > of
> > rd_amcache in
On Tue, 26 Sept 2023 at 02:09, Matthias van de Meent
wrote:
>
> On Tue, 19 Sept 2023 at 01:03, Andres Freund wrote:
> >
> > Hi,
> >
> > On 2023-05-18 19:22:26 +0300, Heikki Linnakangas wrote:
> > > On 18/05/2023 17:59, Matthias van de Meent wrote:
> > > > It changes the block IDs used to fit in
On Mon, 10 Jul 2023 at 14:48, Heikki Linnakangas wrote:
>
> On 09/03/2023 07:34, Thomas Munro wrote:
> > Here is a feature idea that emerged from a pgsql-bugs thread[1] that I
> > am kicking into the next commitfest. Example:
> >
> > s1: \c db1
> > s1: CREATE TABLE t (i int);
> > s1: BEGIN
On Wed, 2 Aug 2023 at 21:34, Tomas Vondra wrote:
>
>
>
> On 8/2/23 17:25, Sergey Dudoladov wrote:
> > Hello,
> >
> >> Parallel version is not supported, but I think it should be possible.
> >
> > @Tomas are you working on this ? If not, I would like to give it a try.
> >
>
> Feel free to try.
On Sat, 2024-01-20 at 13:48 +0700, John Naylor wrote:
> The above identity is not true for this haszero64 macro.
I see.
> I hope this makes it more clear. Maybe the comment could use some
> work.
Yes, thank you. I don't think we need to change the algorithm.
After having stepped away from this
On Sat, Jan 20, 2024 at 5:57 PM Tom Lane wrote:
>
> James Coleman writes:
> > On Sat, Jan 20, 2024 at 12:59 PM Tom Lane wrote:
> >> A HINT if the bogus column name (1) matches the relation name and
> >> (2) is field-qualified seems plausible to me. Then it's pretty
> >> likely to be a user
Peter Eisentraut writes:
> On 20.01.24 17:03, Tom Lane wrote:
>> * I gather that the point here is to change some generated anchor
>> tags. Would any of these tags be things people would be likely
>> to have bookmarked?
> No, because the problem is that the anchor names are randomly generated
James Coleman writes:
> On Sat, Jan 20, 2024 at 12:59 PM Tom Lane wrote:
>> A HINT if the bogus column name (1) matches the relation name and
>> (2) is field-qualified seems plausible to me. Then it's pretty
>> likely to be a user misunderstanding about whether to write the
>> relation name.
>
On 20.01.24 17:03, Tom Lane wrote:
Peter Eisentraut writes:
I think there was general agreement with what this patch is doing, but I
guess it's too boring to actually review the patch in detail. Let's
say, if there are no objections, I'll go ahead and commit it.
I re-read the thread and
On Sat, Jan 20, 2024 at 12:59 PM Tom Lane wrote:
>
> James Coleman writes:
> > I do wonder if it's plausible (and sufficiently easy) to improve the
> > error message here. "column 'foo' of relation 'foo'" makes one thing
> > that you've written foo.foo, (in my real-world case the error message
>
jian he writes:
> Now I see your point. If the transformed plan is right, the whole
> added code should be fine.
> but keeping the textrange_supp related test should be a good idea.
> since we don't have SUBTYPE_OPCLASS related sql tests.
Yeah, it's a little harder to make a table-less test for
James Coleman writes:
> I do wonder if it's plausible (and sufficiently easy) to improve the
> error message here. "column 'foo' of relation 'foo'" makes one thing
> that you've written foo.foo, (in my real-world case the error message
> also cut off the sql past "foo.", and so I couldn't even
On Sat, Jan 20, 2024 at 11:12 AM Tom Lane wrote:
>
> James Coleman writes:
> > Suppose I have this table:
> > create table foo (id int primary key);
>
> > On PG11 this works:
> > postgres=# insert into foo (id) values (1) on conflict (id) do update
> > set foo.id = 1;
> > INSERT 0 1
>
> Hmm, are
So, overall reaction to this patch: I like the approach of defining
"predicate check expressions" as being a different thing from standard
jsonpath expressions. However, I'm not so thrilled with just saying
"don't use" one type or the other with different jsonpath functions.
According to my
"David E. Wheeler" writes:
> While you’re in there, Tom, would it make sense to fold in something like
> [this patch][1] I posted last month to clarify which JSONPath comparison
> operators can take advantage of a index?
> --- a/doc/src/sgml/json.sgml
> +++ b/doc/src/sgml/json.sgml
> @@ -513,7
James Coleman writes:
> Suppose I have this table:
> create table foo (id int primary key);
> On PG11 this works:
> postgres=# insert into foo (id) values (1) on conflict (id) do update
> set foo.id = 1;
> INSERT 0 1
Hmm, are you sure about that? I get
ERROR: column "foo" of relation "foo"
Peter Eisentraut writes:
> I think there was general agreement with what this patch is doing, but I
> guess it's too boring to actually review the patch in detail. Let's
> say, if there are no objections, I'll go ahead and commit it.
I re-read the thread and have two thoughts:
* We worried
On Jan 19, 2024, at 21:46, Erik Wienhold wrote:
> Interesting... copy-pasting the entire \set command works for me with
> psql 16.1 in gnome-terminal and tmux. Typing it out manually gives me
> the "unterminated quoted string" error. Maybe has to do with my stty
> settings.
Yes, same on macOS
On Saturday, January 20, 2024, James Coleman wrote:
>
>
> Well, egg on my face for definitely missing that in the docs.
>
> Unfortunately that doesn't explain why it works on PG11 and not on PG12.
>
It was a bug that got fixed. I’m sure a search of the mailing list
archives or Git will turn up
On Fri, Jan 19, 2024 at 1:53 PM David G. Johnston
wrote:
>
> On Fri, Jan 19, 2024 at 10:01 AM James Coleman wrote:
>>
>> Making this more confusing is the fact that if I want to do something
>> like "SET bar = foo.bar + 1" the table qualification cannot be present
>> on the setting column but is
On Sat, Jan 20, 2024 at 10:52 AM Dilip Kumar wrote:
>
> On Fri, Jan 19, 2024 at 5:24 PM Amit Kapila wrote:
> >
> > On Wed, Jan 17, 2024 at 4:00 PM shveta malik wrote:
> > >
> >
> > I had some off-list discussions with Sawada-San, Hou-San, and Shveta
> > on the topic of extending replication
On 20.01.24 03:33, vignesh C wrote:
On Fri, 25 Aug 2023 at 01:23, Tristan Partin wrote:
On Thu Aug 24, 2023 at 2:30 PM CDT, Tom Lane wrote:
"Tristan Partin" writes:
On Wed Aug 23, 2023 at 2:24 PM CDT, Peter Eisentraut wrote:
Somewhere at PGCon, I forgot exactly where, maybe in the same
On 15.01.24 09:54, Nazir Bilal Yavuz wrote:
Hi,
On Wed, 10 Jan 2024 at 23:48, Peter Eisentraut wrote:
On 05.09.23 19:26, Nazir Bilal Yavuz wrote:
Thanks for the feedback! I updated the patch, 'needs-private-lo'
option enables kerberos, ldap, load_balance and ssl extra tests now.
As was
24 matches
Mail list logo
