Storing files in the database has already been demonstrated as not an
efficient trade-off [0]. As such, this post provides a subjective story
about files in the database, rather than an objective compare.
So, I have this ridiculous situation where dumping a database with 12k
user-submitted forms w
On 2019-04-17 18:41:57 +0200, Francisco Olarte wrote:
> On Wed, Apr 17, 2019 at 4:49 PM Ajay Pratap
> wrote:
> > Correction: I meant when my java application dies postgres should break all
> > the connections that were associated with that peer.
>
> And how is the server supposed to detect that
When I created the database I set primary key data types as integer; for
example:
Column| Type | Collation | Nullable | Default
--+---+---+--+-
org_id | integer | | not null |
nextval('organizations_o
On 4/19/19 10:55 AM, Rich Shepard wrote:
When I created the database I set primary key data types as integer; for
example:
Column | Type | Collation | Nullable | Default
--+---+---+--+-
org_id | integer |
On Fri, Apr 19, 2019 at 10:55 AM Rich Shepard
wrote:
> When I created the database I set primary key data types as integer; for
> example:
>
> Column| Type | Collation | Nullable | Default
> --+---+---+--+-
> org_id |
On Fri, 19 Apr 2019, Michel Pelletier wrote:
https://www.postgresql.org/docs/current/datatype-numeric.html#DATATYPE-SERIAL
"The data types smallserial, serial and bigserial are not true types, but
merely a notational convenience for creating unique identifier columns"
so really there's no differ
On Fri, 19 Apr 2019, Adrian Klaver wrote:
If it is working for you now I see no reason to switch.
Adrian,
It does work. I just learned about the SQL identity type and want to learn
when it's most appropriate to use. The databases I develop all work with
integers as primary keys and reading ab
On 4/19/19 11:14 AM, Rich Shepard wrote:
On Fri, 19 Apr 2019, Adrian Klaver wrote:
If it is working for you now I see no reason to switch.
Adrian,
It does work. I just learned about the SQL identity type and want to learn
when it's most appropriate to use. The databases I develop all work wi
On Fri, Apr 19, 2019 at 11:20 AM Adrian Klaver
wrote:
> On 4/19/19 11:14 AM, Rich Shepard wrote:
> > On Fri, 19 Apr 2019, Adrian Klaver wrote:
> >
> >> If it is working for you now I see no reason to switch.
> >
> > Adrian,
> >
> > It does work. I just learned about the SQL identity type and want
On Fri, 19 Apr 2019, Adrian Klaver wrote:
Mainly for folks that want cross database SQL compliance. It is not a type
so much as a way of specifying an auto-increment column.
Thank you, Adrian. I saw that it was a column specification and your
explanation of its application is really helpful.
On 4/19/19 11:32 AM, Ken Tanzer wrote:
On Fri, Apr 19, 2019 at 11:20 AM Adrian Klaver
mailto:adrian.kla...@aklaver.com>> wrote:
On 4/19/19 11:14 AM, Rich Shepard wrote:
> On Fri, 19 Apr 2019, Adrian Klaver wrote:
>
>> If it is working for you now I see no reason to switch.
On 4/19/19 11:32 AM, Ken Tanzer wrote:
On Fri, Apr 19, 2019 at 11:20 AM Adrian Klaver
mailto:adrian.kla...@aklaver.com>> wrote:
On 4/19/19 11:14 AM, Rich Shepard wrote:
> On Fri, 19 Apr 2019, Adrian Klaver wrote:
>
>> If it is working for you now I see no reason to switch.
On Fri, Apr 19, 2019 at 12:02 PM Adrian Klaver
wrote:
> On 4/19/19 11:32 AM, Ken Tanzer wrote:
> > On Fri, Apr 19, 2019 at 11:20 AM Adrian Klaver
> > mailto:adrian.kla...@aklaver.com>> wrote:
> >
> > On 4/19/19 11:14 AM, Rich Shepard wrote:
> > > On Fri, 19 Apr 2019, Adrian Klaver wrote:
On 4/19/19 12:35 PM, Ken Tanzer wrote:
Thanks Adrian. You are as usual correct. (I had a bunch of tables
created by a function that I assumed were serial, but were not.)
Identity columns still seem tidier and more manageable. Can you tell if
the function I referenced would change the own
On Fri, Apr 19, 2019 at 12:50 PM Adrian Klaver
wrote:
> On 4/19/19 12:35 PM, Ken Tanzer wrote:
>
> >
> > Thanks Adrian. You are as usual correct. (I had a bunch of tables
> > created by a function that I assumed were serial, but were not.)
> > Identity columns still seem tidier and more managea
On 4/19/19 1:02 PM, Ken Tanzer wrote:
On Fri, Apr 19, 2019 at 12:50 PM Adrian Klaver
mailto:adrian.kla...@aklaver.com>> wrote:
On 4/19/19 12:35 PM, Ken Tanzer wrote:
>
> Thanks Adrian. You are as usual correct. (I had a bunch of tables
> created by a function that I assume
On Fri, Apr 19, 2019 at 1:39 PM Adrian Klaver
wrote:
> On 4/19/19 1:02 PM, Ken Tanzer wrote:
> > On Fri, Apr 19, 2019 at 12:50 PM Adrian Klaver
> > mailto:adrian.kla...@aklaver.com>> wrote:
> >
> > On 4/19/19 12:35 PM, Ken Tanzer wrote:
> >
> > >
> > > Thanks Adrian. You are as usu
On 4/19/19 2:31 PM, Ken Tanzer wrote:
On Fri, Apr 19, 2019 at 1:39 PM Adrian Klaver
Thanks, though I don't see what this shows, since there were not
separate users involved. So I loaded up a copy of 11.2, and discovered
Well the table was created by one user and the serial was changed to
I forgot to mention that my deployments include automated migrations as
often as possible, sometimes destructive for refactoring purpose, as such,
to maintain PostgreSQL on a basic linux box I am:
- for having an automated backup prior in the automated deployment script
that may play destructive m
19 matches
Mail list logo
