Re: Can we go beyond the standard to make Postgres radically better?

2022-02-13 Thread Peter J. Holzer
On 2022-02-13 01:11:16 +0100, Andreas 'ads' Scherbaum wrote: > On 12/02/2022 22:34, Peter J. Holzer wrote: > > On 2022-02-12 22:09:25 +0100, Andreas 'ads' Scherbaum wrote: > > > On 12/02/2022 20:50, Peter J. Holzer wrote: > > > > On 2022-02-12 01:18:04 +0100, Andreas 'ads' Scherbaum wrote: > > > >

Re: Can we go beyond the standard to make Postgres radically better?

2022-02-13 Thread Peter J. Holzer
On 2022-02-12 20:12:02 -0500, Mladen Gogala wrote: > On 2/12/22 19:11, Andreas 'ads' Scherbaum wrote: > > The complaint is not about complex queries, or CTEs, or Joins. This is > about simple queries where a user wants to discover - surf - the database > and look into specific tables,

Re: Can we go beyond the standard to make Postgres radically better?

2022-02-13 Thread Pavel Stehule
ne 13. 2. 2022 v 9:29 odesílatel Peter J. Holzer napsal: > On 2022-02-13 01:11:16 +0100, Andreas 'ads' Scherbaum wrote: > > On 12/02/2022 22:34, Peter J. Holzer wrote: > > > On 2022-02-12 22:09:25 +0100, Andreas 'ads' Scherbaum wrote: > > > > On 12/02/2022 20:50, Peter J. Holzer wrote: > > > > >

Re: Can we go beyond the standard to make Postgres radically better?

2022-02-13 Thread Guyren Howe
> > The MySQL autocomplete is designed without context filtering. Maybe we can > > have this implementation too (as alternative) > > > > so using all column names + all table names + aliases.column names (when we > > know defined alias) > > > > Another idea about column excluding. Any implementa

Re: Can we go beyond the standard to make Postgres radically better?

2022-02-13 Thread Pavel Stehule
ne 13. 2. 2022 v 10:45 odesílatel Guyren Howe napsal: > > The MySQL autocomplete is designed without context filtering. Maybe we can > have this implementation too (as alternative) > > so using all column names + all table names + aliases.column names (when > we know defined alias) > > Another id

How to split normal and overtime hours

2022-02-13 Thread Andrus
Hi! Hours table contains working hours for jobs:     create table hours (     jobid integer primary key, -- job done, unique for person     personid char(10) not null, -- person who did job     hours numeric(5,2) not null -- hours worked for job     ) Hours more than 120 are overtime hours. Ho

Re: How to split normal and overtime hours

2022-02-13 Thread Torsten Förtsch
something like SELECT * , least(sum(hours) OVER w, 120) AS regular , greatest(sum(hours) OVER w - 120, 0) AS overtime FROM hours WINDOW w AS (PARTITION BY person ORDER BY job_id); job_id | person | hours | regular | overtime ++---+-+-- 2 | bi

Re: How to split normal and overtime hours

2022-02-13 Thread Torsten Förtsch
WITH x AS ( SELECT * , sum(hours) OVER w AS s FROM hours WINDOW w AS (PARTITION BY person ORDER BY job_id) ) SELECT * , greatest(least(s, 120) - coalesce(lag(s, 1) OVER w, 0), 0) AS regular , hours - greatest(least(s, 120) - coalesce(lag(s, 1) OVER w, 0), 0) AS overtime

Re: Can we go beyond the standard to make Postgres radically better?

2022-02-13 Thread Mladen Gogala
On 2/13/22 05:00, Pavel Stehule wrote: But there can be a valid second question - it can be nice to use extensions with availability to define their own communication protocol. Postgres has a special protocol for replication or for backup. With this possibility you can do what you need without

FDW error on remote view

2022-02-13 Thread Michael Mauger
I'm working on building a demonstration of this error, but I figured I'd ask the question first. BACKGROUND I've got two databases, stage and app. There is a postgres_fdw connection between them so that stage can see objects in the app database. The app database contains complex metadata that is

Re: FDW error on remote view

2022-02-13 Thread Tom Lane
Michael Mauger writes: > Why is there an error in the app context only when I invoke the view > through a FOREIGN TABLE. And more importantly, how do I get around it? It's hard to be sure with this amount of detail, but I think what is happening is that your view invokes a plpgsql function and th