Hi!
Working on pluggable toaster (mostly, for JSONB improvements, see links
below) I had found that STORAGE attribute on column is impossible to set
in CREATE TABLE command but COMPRESS option is possible. It looks
unreasonable. Suggested patch implements this possibility.
[1]
Dear Fujii-san,
> Attached is the patch that adds the regression test for
> postgres_fdw.application_name. Could you review this?
>
> As Horiguchi-san suggested at [1], I split the test into two, and then
> tweaked them
> as follows.
>
> 1. Set application_name option of a server option to
On 2021/12/27 10:40, kuroda.hay...@fujitsu.com wrote:
Dear Fujii-san, Horiguchi-san,
I confirmed that the feature was committed but reverted the test.
Now I'm checking buildfarm.
Attached is the patch that adds the regression test for
postgres_fdw.application_name. Could you review this?
On Thu, Dec 16, 2021 at 2:42 PM Masahiko Sawada wrote:
>
> On Thu, Dec 16, 2021 at 2:21 PM Amit Kapila wrote:
> >
> > On Thu, Dec 16, 2021 at 10:37 AM Masahiko Sawada
> > wrote:
> > >
> > > On Thu, Dec 16, 2021 at 11:43 AM Amit Kapila
> > > wrote:
> > > >
> > > > I thought we just want to
On Mon, Nov 15, 2021 at 04:38:56PM -0600, Justin Pryzby wrote:
> On Sun, Aug 29, 2021 at 07:26:42PM -0500, Justin Pryzby wrote:
> > On Mon, Jun 28, 2021 at 11:22:01AM +0300, Anna Akenteva wrote:
> > > On 2019-11-29 05:32, Michael Paquier wrote:
> > > > These comments are unanswered for more than 2
Dear Fujii-san, Horiguchi-san,
I confirmed that the feature was committed but reverted the test.
Now I'm checking buildfarm.
But anyway I want to say thank you for your contribution!
Best Regards,
Hayato Kuroda
FUJITSU LIMITED
On Sun, Dec 26, 2021, at 1:09 PM, Alvaro Herrera wrote:
> On 2021-Dec-26, Euler Taveira wrote:
>
> > On Sat, Dec 25, 2021, at 1:20 AM, Amit Kapila wrote:
> > > On Fri, Dec 24, 2021 at 11:04 AM Peter Smith
> > > wrote:
> > > >
> > > > So, IMO the PG docs wording for this part should be relaxed a
>
>
>
> Perhaps this would be more SQL idiomatic:
>
> FROM permission p
>LEFT JOIN ON KEY role IN p AS r
>LEFT JOIN team_role AS tr ON KEY role TO r
>LEFT JOIN ON KEY team IN tr AS t
>LEFT JOIN user_role AS ur ON KEY role TO r
>LEFT JOIN ON KEY user IN ur AS u
>
>
My second
On Sun, Dec 26, 2021, at 22:38, Joel Jacobson wrote:
> FROM permission p
> LEFT JOIN ON KEY p.role r
> LEFT JOIN team_role tr ON KEY role TO r
> LEFT JOIN ON KEY tr.team t
> LEFT JOIN user_role ur ON KEY role TO r
> LEFT JOIN ON KEY ur.user u
Hm, might be problematic to reuse dot
When you join by id, the join is unique. You can have combinations of
fields, with multiple fields. Is it a maximum fields question.
Isaac Morland schrieb am So., 26. Dez. 2021,
22:37:
> On Sun, 26 Dec 2021 at 16:24, Joel Jacobson wrote:
>
>
>> I think if we combine the ON KEY ... TO ... part
On Sun, Dec 26, 2021, at 22:24, Joel Jacobson wrote:
> FROM permission p
>LEFT JOIN ON KEY p.permission_role_id_fkey r
>LEFT JOIN team_role tr ON KEY team_role_role_id_fkey TO r
>LEFT JOIN ON KEY tr.team_role_team_id_fkey t
>LEFT JOIN user_role ur ON KEY user_role_role_id_fkey TO r
On Sun, 26 Dec 2021 at 16:24, Joel Jacobson wrote:
> I think if we combine the ON KEY ... TO ... part of my idea, with your
> idea, we have a complete neat solution.
>
> Maybe we can make them a little more similar syntax wise though.
>
> Could you accept "ON KEY" instead of "FOREIGN KEY" for
On Sun, Dec 26, 2021, at 21:49, Isaac Morland wrote:
> Right, sorry, that was sloppy of me. I should have noticed that I wrote "tr->
> ... AS tr". But in the case where the "source"
> (referencing) table is already in the join, what's wrong with allowing my
> suggestion? We do need another way
On Sun, Dec 26, 2021, at 19:52, Joel Jacobson wrote:
>LEFT JOIN role r ON KEY p.permission_role_id_fkey
Ops! I see this doesn't quite work.
We're missing one single bit of information.
That is, we need to indicate if the foreign key is
a) in the table we're currently joining
or
b) to some
On Sun, 26 Dec 2021 at 14:37, Joel Jacobson wrote:
> Let's look at each row your example and see if we can work it out.
> I've added the "FROM permission p" and also "AS [table alias]",
> otherwise the aliases you use won't exist.
>
> > FROM permission p
>
> This row is obviously OK. We now
On Sun, Dec 26, 2021, at 20:02, Isaac Morland wrote:
> Is it going too far to omit the table name? I mean, any given foreign key can
> only point to one other table:
That actually how I envisioned this feature to work way back, but it doesn't
work, and I'll try to explain why.
As demonstrated,
On Sun, 26 Dec 2021 at 01:47, Joel Jacobson wrote:
> On Sat, Dec 25, 2021, at 21:55, Joel Jacobson wrote:
> > FROM permission p
> > LEFT JOIN role r WITH p->permission_role_id_fkey = r
> > LEFT JOIN team_role tr WITH tr->team_role_role_id_fkey = r
> > LEFT JOIN team t WITH
On Sun, Dec 26, 2021, at 19:54, Sascha Kuhl wrote:
> Could you make
>
> JOIN key ?
Not sure what you mean.
Perhaps you can explain by rewriting the normal query below according to your
idea?
SELECT *
FROM permission p
LEFT JOIN role r ON p.role_id = r.id
Given the foreign key on "permission"
Could you make
JOIN key ?
Joel Jacobson schrieb am So., 26. Dez. 2021, 19:52:
> On Sun, Dec 26, 2021, at 19:33, Sascha Kuhl wrote:
> > The Syntax is great. Which language does it come from. I consider it not
> german. But I understand it mathematically.
> > Great extension.
>
> It doesn't come
On Sun, Dec 26, 2021, at 19:33, Sascha Kuhl wrote:
> The Syntax is great. Which language does it come from. I consider it not
> german. But I understand it mathematically.
> Great extension.
It doesn't come from any language. But I've seen similar features in ORMs, such
as the jOOQ Java
On 2021-Dec-26, Euler Taveira wrote:
> On Sat, Dec 25, 2021, at 1:20 AM, Amit Kapila wrote:
> > On Fri, Dec 24, 2021 at 11:04 AM Peter Smith wrote:
> > >
> > > So, IMO the PG docs wording for this part should be relaxed a bit.
> > >
> > > e.g.
> > > BEFORE:
> > > + A nullable column in the
On Sat, Dec 25, 2021, at 1:20 AM, Amit Kapila wrote:
> On Fri, Dec 24, 2021 at 11:04 AM Peter Smith wrote:
> >
> > So, IMO the PG docs wording for this part should be relaxed a bit.
> >
> > e.g.
> > BEFORE:
> > + A nullable column in the WHERE clause could cause the
> > + expression to
On Fri, Dec 24, 2021 at 11:41:47AM +1100, Peter Smith wrote:
> The most recent cfbot run for a patch I am interested in has failed a
> newly added regression test.
>
> Please see http://cfbot.cputube.org/ for 36/2906
>
> The failure logs [2] are very curious because the error message is
> what
>> 8 апр. 2021 г., в 15:22, Thomas Munro написал(а):
>>
> I have one more idea inspired by CPU caches.
> Let's make SLRU n-associative, where n ~ 8.
> We can divide buffers into "banks", number of banks must be power of 2.
> All banks are of equal size. We choose bank size to approximately
On Thu, Dec 23, 2021 at 09:16:02PM +0530, Bharath Rupireddy wrote:
> Thanks. I thought of having a macro, but it creates a lot of diff with
> the previous versions as we have to change for other pg_control_XXX
> functions.
Yeah, I was wondering about that, but that's not worth the potential
25 matches
Mail list logo
