Re: Whither 1:1?

Olivier Gautherot writes: > On Fri, Jun 1, 2018 at 12:52 PM, Guyren Howe wrote: > >> It’s come to my attention that what seems an obvious and useful database >> design pattern — 1:1 relations between tables by having a shared primary >> key — is hardly discussed or used. >> >> It would seem

notes from transition to relkind='p'

Before I forget any more, this is a brain of issues/considerations/concerns with our (partial) transition to partitioned tables over the last ~9 months. I believe these are all documented behaviors, but could be seen by users as a gratuitious/unexpected change or rough edge and the differences

Re: RPM Packaging Question - Fedora 28 & Postgis

On 06/01/2018 10:27 AM, John Woltman wrote: According to "dnf info", the repo is pgdg95, which I got from the Postgres website.  Since this looks like a packaging bug and not specifically a Postgres bug, should I submit it pgsql-b...@postgresql.org ? No I

Re: RPM Packaging Question - Fedora 28 & Postgis

According to "dnf info", the repo is pgdg95, which I got from the Postgres website. Since this looks like a packaging bug and not specifically a Postgres bug, should I submit it pgsql-b...@postgresql.org? -John John Woltman TPI • 302 New Mill Lane • Exton, PA 19341 • (610) 524-7260 On Fri, Jun

Re: Whither 1:1?

On Jun 1, 2018, at 10:16 , Olivier Gautherot wrote: > > You will get a benefit in terms of space only if the optional fields in the > second table exist in a reduced number of instances - and the second table is > significantly wider. This can make a difference on big tables but this gain >

Re: Whither 1:1?

On Fri, Jun 1, 2018 at 12:52 PM, Guyren Howe wrote: > It’s come to my attention that what seems an obvious and useful database > design pattern — 1:1 relations between tables by having a shared primary > key — is hardly discussed or used. > > It would seem to be a very simple pattern, and useful

Re: RPM Packaging Question - Fedora 28 & Postgis

John Woltman writes: > I'm attempting to install PostGIS2 (specifically postgis2_95 for Postgres > 9.5) on Fedora 28. When I run ``sudo dnf install postgis23_95`` I get the > the following the error: > Error: > Problem: conflicting requests > - nothing provides geos36 >= 3.6.2 needed by

Re: RPM Packaging Question - Fedora 28 & Postgis

On 06/01/2018 10:06 AM, John Woltman wrote: I'm attempting to install PostGIS2 (specifically postgis2_95 for Postgres 9.5) on Fedora 28.  When I run ``sudo dnf install postgis23_95`` I get the the following the error: Error:   Problem: conflicting requests - nothing provides geos36 >=

RPM Packaging Question - Fedora 28 & Postgis

I'm attempting to install PostGIS2 (specifically postgis2_95 for Postgres 9.5) on Fedora 28. When I run ``sudo dnf install postgis23_95`` I get the the following the error: Error: Problem: conflicting requests - nothing provides geos36 >= 3.6.2 needed by postgis23_95 Fedora 28 provides

Re: Whither 1:1?

On Jun 1, 2018, at 10:00 , James Keener wrote: > > I don't think I fully understand. Do you mean all pk using a single sequence? > I’m not sure how this would avoid nulls or grouping fields. Presumably, you would create the multiple tables together or after some main one or something where

Re: Whither 1:1?

2018-06-01 18:52 GMT+02:00 Guyren Howe : > It’s come to my attention that what seems an obvious and useful database > design pattern — 1:1 relations between tables by having a shared primary > key — is hardly discussed or used. > > It would seem to be a very simple pattern, and useful to avoid

Re: Whither 1:1?

I don't think I fully understand. Do you mean all pk using a single sequence? I'm not sure how this would avoid nulls or grouping fields. Jim On Fri, Jun 1, 2018 at 12:52 PM, Guyren Howe wrote: > It’s come to my attention that what seems an obvious and useful database > design pattern — 1:1

Re: Whither 1:1?

On Fri, Jun 1, 2018 at 9:52 AM, Guyren Howe wrote: > It’s come to my attention that what seems an obvious and useful database > design pattern — 1:1 relations between tables by having a shared primary > key — is hardly discussed or used. > > It would seem to be a very simple pattern, and useful

Whither 1:1?

It’s come to my attention that what seems an obvious and useful database design pattern — 1:1 relations between tables by having a shared primary key — is hardly discussed or used. It would seem to be a very simple pattern, and useful to avoid storing nulls or for groups of fields that tend to

Re: Pgagent is not reading pgpass file either in Windows or Linux.

On Thu, May 31, 2018 at 5:16 PM, George Neuner wrote: > On Thu, 31 May 2018 15:40:21 -0500, nageswara Bandla > wrote: > > >On Thu, May 31, 2018 at 12:57 PM, George Neuner > >wrote: > > > >> It just occurred to me that you said PGPASSFILE was set to > >> > >>

Re: Sort is generating rows

On 06/01/2018 02:36 AM, Nicolas Seinlet wrote: Hi, thanks for the answer. The query is based on a view, so here are the view, the query as well as the query plan. I've already taken into account remarks like date ranges. You changed the query from the original, besides just adding the

Re: reduce number of multiple values to be inserted

On Wed, 30 May 2018 08:10:05 +0800 tango ward wrote: > curr_pgsql.execute(''' >INSERT INTO student (created, modified, name, > address, age, > level ) >VALUES (current_timezone, current_timezone, >

Re: VBA to connect to postgresql from MS Access

Le 01-06-18 à 14:21, Łukasz Jarych a écrit : ODBC;DSN=PostgreSQL35W;DATABASE=AccessTest;SERVER=localhost;PORT=5432;*CA=d;A7=100;B0=255;B1=8190;BI=0;C2=;CX=1c305008b;A1=7.4* When i was searching code for this in internet i found only: DRIVER={PostgreSQL

VBA to connect to postgresql from MS Access

Hi Guys, When i have linked table based on DSN odbc connection to postgresql , i am going to : VBA editor, in immediate window inputing: ?CurrentDb.TableDefs("TableName").Connect i have very strange connection string:

Re: Question on disk contention

For the sake of completeness I think i have to slightly correct myself. While I cannot find it in the documentation, (if somebody has pointers, please provide them) on my personal notes I found that 'if a scan is already in progress, and a new scan starts, then the new scan will start where the

Re: Sort is generating rows

Hi, thanks for the answer. The query is based on a view, so here are the view, the query as well as the query plan. I've already taken into account remarks like date ranges. SELECT min(l.id) AS id, l.product_id, t.uom_id AS product_uom, sum(l.product_uom_qty / u.factor * u2.factor)