Tim, I'm sorry if I sound like a cheerleader, but boy did you nail this. I
would basically say exactly the same thing, just not as well.
On Sun, Apr 8, 2018 at 9:37 PM, Tim Cross wrote:
>
>
> On 9 April 2018 at 07:39, Guyren Howe wrote:
>
>> I am a Rails developer at a medium-large size compa
On 9 April 2018 at 07:39, Guyren Howe wrote:
> I am a Rails developer at a medium-large size company. I’ve mostly worked
> at smaller companies. I’ve some exposure to other web development
> communities.
>
> When it comes to databases, I have universally encountered the attitude
> that one should
Greetings,
* Ravi Krishna (sravikrish...@gmail.com) wrote:
> >> I am however very comfortable with using psql and PL/pgSQL and I am very
> >opinionated.
> >
> Nothing wrong with this approach and it may very well work 90% of the time.
> Until ... a day comes when
> you need to migrate out of PG to
Greetings,
* Alvaro Aguayo Garcia-Rada (aagu...@opensysperu.com) wrote:
> 1. Portability. Being tied to a single database engine is not always a good
> idea. When you write business logic in database, you have to write and
> maintain your store procedures for every database engine you want to su
> I am however very comfortable with using psql and PL/pgSQL and I am
very opinionated.
Nothing wrong with this approach and it may very well work 90% of the
time. Until ... a day comes when
you need to migrate out of PG to another RDBMS. Good luck at that time.
On April 8, 2018 02:40:46 pm PDT, "Guyren Howe" wrote:
I am a Rails developer at a medium-large size company. I’ve mostly
worked at smaller companies. I’ve some exposure to other web
development communities.
When it comes to databases, I have universally encountered the attitude
that o
On 04/08/2018 02:39 PM, Guyren Howe wrote:
I am a Rails developer at a medium-large size company. I’ve mostly
worked at smaller companies. I’ve some exposure to other web development
communities.
When it comes to databases, I have universally encountered the attitude
that one should treat the
1. With a micro service based architecture these days, it is difficult to
justify putting all logic in a central database as you can only scale up in
a database. Business logic in things like Spark can make a claim for scale
out solution.
2. All RDBMS have a non portable stored proc language, maki
Let's see There are two major issues when writing business logic in
database:
1. Portability. Being tied to a single database engine is not always a good
idea. When you write business logic in database, you have to write and maintain
your store procedures for every database engine you want
I am a Rails developer at a medium-large size company. I’ve mostly worked at
smaller companies. I’ve some exposure to other web development communities.
When it comes to databases, I have universally encountered the attitude that
one should treat the database as a dumb data bucket. There is a *v
On 04/08/2018 11:01 AM, Rory Campbell-Lange wrote:
Thanks for your comprehensive response, Adrian.
Fair enough. It is however a tedious problem to resolve in a large
code base and it would be cool to have a new "--set-search-path"
option to pg_dump to override it.
From other posts that cove
Thanks for your comprehensive response, Adrian.
On 08/04/18, Adrian Klaver (adrian.kla...@aklaver.com) wrote:
> On 04/08/2018 03:40 AM, Rory Campbell-Lange wrote:
> > On 07/04/18, Adrian Klaver (adrian.kla...@aklaver.com) wrote:
> > > > (I'm aware that the reasons behind the change made to the dum
On 04/07/2018 03:44 AM, Đỗ Ngọc Trí Cường wrote:
Dear all,
I've found one case. I don't know this is a bug or I config/query some
things wrong.
Let I describe it. I have a table with structure and data is:
id | username | fullname
+-+---
1 | john | J
On Sun, Apr 8, 2018 at 11:28 AM, pinker wrote:
>
>
> It's kinda mysterious... Any explanations?
> Does it mean that the same buffers were written over and over again?
>
>
Yeah, checkpoints will write all dirty buffers, but doesn't evict them.
Next time the page is needed, it doesn't need to be re
Hi All!
First time I see that the sum of written buffers:
3765929+878326121 = 882092050 = select
pg_size_pretty(882092050::numeric*8192) = 6730 GB
is bigger than buffers_alloc value in pg_stat_bgwriter view:
buffers_alloc | 20426161 = 156 GB
buffers_checkpoint| 878599316
buffers_cle
On 04/08/2018 03:40 AM, Rory Campbell-Lange wrote:
On 07/04/18, Adrian Klaver (adrian.kla...@aklaver.com) wrote:
(I'm aware that the reasons behind the change made to the dump format
due to CVE-2018-1058 are set out here:
https://wiki.postgresql.org/wiki/A_Guide_to_CVE-2018-1058:_Protect_Your_Se
On 07/04/18, Adrian Klaver (adrian.kla...@aklaver.com) wrote:
> > (I'm aware that the reasons behind the change made to the dump format
> > due to CVE-2018-1058 are set out here:
> > https://wiki.postgresql.org/wiki/A_Guide_to_CVE-2018-1058:_Protect_Your_Search_Path)
> >
>
> > Additionally we som
17 matches
Mail list logo
