Re: [GENERAL] "Reverse" inheritance?

I have thought of doing something like a single table inheritance and it could be done but I thought this might be a little more elegant. On Tue, Apr 4, 2017 at 2:15 PM, David G. Johnston < david.g.johns...@gmail.com> wrote: > On Mon, Apr 3, 2017 at 7:07 PM, Tim Uckun wrote:

Re: [GENERAL] "Reverse" inheritance?

On Mon, Apr 3, 2017 at 7:07 PM, Tim Uckun wrote: > I am trying to make postgres tables work like an object hierarchy. As an > example I have done this. > ​I suspect you are barking up the wrong tree ;) You are probably better off incorporating something like the "ltree"

[GENERAL] "Reverse" inheritance?

I am trying to make postgres tables work like an object hierarchy. As an example I have done this. drop table if exists os.linux cascade; create table os.linux ( script_name character varying(255) NOT NULL, script_body text, CONSTRAINT os_linux_pkey PRIMARY KEY (script_name) ); drop table if

Re: [GENERAL] My humble tribute to psql -- usql v0.5.0

On Mon, Apr 3, 2017 at 4:42 PM, Kenneth Shaw wrote: > UTF-8 works just fine with MS SQL: > > ms:booktest@192.168.1.5=> select N'这是一个'; > col0 > +--+ > 这是一个 > (1 rows) confirmed! merlin -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To

Re: [GENERAL] My humble tribute to psql -- usql v0.5.0

UTF-8 works just fine with MS SQL: ms:booktest@192.168.1.5=> select N'这是一个'; col0 +--+ 这是一个 (1 rows) You need to use a "unicode" string, as indicated here using N''. You might be able to change the default behavior in SQL Server to treat strings as unicode strings, by changing the

Re: [GENERAL] My humble tribute to psql -- usql v0.5.0

This doesn't seem to be a problem with PostgreSQL, MySQL, Oracle, or SQLite3 databases. It was a problem with MSSQL in the limited check that I just did. I don't see any driver option for the MSSQL Go driver. I'll poke around and see if there's a "client encoding" option. -Ken On Tue, Apr 4,

Re: [GENERAL] My humble tribute to psql -- usql v0.5.0

On Mon, Apr 3, 2017 at 8:51 PM, Merlin Moncure wrote: > Wow! this is _fantastic_. I use "sqsh" for connecting to sql server > -- this is already a significant improvement in many ways (based on > playing around for around 10 minutes). This app would fill a real > need for

Re: [GENERAL] PostgreSQL and Kubernetes

> On 30. Mar 2017, at 12:10, Moreno Andreo wrote: > as databases aren't built for type of dynamic scheduling that something like > kubernetes (or any other container management solution), due to how they > interact with the filesystem, network stack, and more. >

Re: [GENERAL] spin locks and starvation

On Mon, 3 Apr 2017 11:40:29 +0200, Tom DalPozzo wrote: >I saw that postgresql implementation makes big use of spin locks. >I was wondering if I should be concerned about possible starvation problem >because I looked around and couldn't find an absolute answer about if linux

Re: [GENERAL] PostgreSQL and Kubernetes

On 03/31/2017 01:58 AM, Moreno Andreo wrote: > Il 30/03/2017 14:38, Vick Khera ha scritto: >> >> On Thu, Mar 30, 2017 at 6:10 AM, Moreno Andreo >> > wrote: >> >> Since I'm on Google Cloud Platform, I thought it would be a good >>

Re: [GENERAL] Unexpected interval comparison

Kyotaro HORIGUCHI writes: > Ok, the attached patch changes the result type of > interval_cmp_value from TimeOffset(=int64) to new 128 bit > LinearInterval. The value is hidden under the functions > interval_eq/ge.../cmp and all other stuff seems to use the >

Re: [GENERAL] My humble tribute to psql -- usql v0.5.0

On Sun, Apr 2, 2017 at 7:55 AM, Kenneth Shaw wrote: > Hi All, > > I apologize in advance if this is somewhat off-topic, but I thought I > would inform the people (ie, psql users) about usql, a > universal-command line tool that aims to work the same way psql does, > but with

Re: [GENERAL] Oddity with time zones.

Steve Rogerson writes: > # select (now()); > now > --- > 2017-04-03 11:57:09.891043+01 > (1 row) > sjr_local1db=# select (now() AT TIME ZONE 'UTC'); > timezone > > 2017-04-03

Re: [GENERAL] Unexpected interval comparison

Hmm. It took a bit longer time than expected. At Fri, 31 Mar 2017 13:29:24 -0400, Tom Lane wrote in <10353.1490981...@sss.pgh.pa.us> > Kyotaro HORIGUCHI writes: > > int128 is seen in numeric.c. It is doable in the same manner. In > > that

[GENERAL] Oddity with time zones.

# select (now()); now --- 2017-04-03 11:57:09.891043+01 (1 row) sjr_local1db=# select (now() AT TIME ZONE 'UTC'); timezone 2017-04-03 10:57:11.714571 (1 row) sjr_local1db=# select (now() AT TIME ZONE 'UTC') AT

[GENERAL] spin locks and starvation

Hi, I saw that postgresql implementation makes big use of spin locks. I was wondering if I should be concerned about possible starvation problem because I looked around and couldn't find an absolute answer about if linux spinlocks guarantee protection about starvation or not. I'm using ubuntu

Re: [GENERAL] Suggestion to improve select pg_reload_conf()

On Mon, Apr 3, 2017 at 4:39 PM, Achilleas Mantzios wrote: > On 03/04/2017 10:31, Thomas Kellerer wrote: >> >> I would like to suggest an improvement to the select pg_reload_conf() >> function. >> >> Currently this will only return true or false indicating if

Re: [GENERAL] Suggestion to improve select pg_reload_conf()

On 03/04/2017 10:31, Thomas Kellerer wrote: I would like to suggest an improvement to the select pg_reload_conf() function. Currently this will only return true or false indicating if reloading was successful. I think it would be a "nice-to-have" if the function would also return the GUCs

[GENERAL] Suggestion to improve select pg_reload_conf()

I would like to suggest an improvement to the select pg_reload_conf() function. Currently this will only return true or false indicating if reloading was successful. I think it would be a "nice-to-have" if the function would also return the GUCs that have been changed, similar to what is being