Adrian,
The drop policy IF EXISTS does work.
But it would be nice to have the IF NOT EXISTS on CREATE POLICY so I don't need
to do a drop and create.
From: Adrian Klaver
Sent: October 20, 2025 14:51
To: Paul Austin ;
[email protected]
Subject
On 10/20/25 14:49, Paul Austin wrote:
I forgot DROP POLICY already has IF EXISTS
I take it that works for you?
*From:*Paul Austin
*Sent:* October 20, 2025 2:46 PM
*To:* [email protected]
*Subject:* Extend CREATE POLICY to add IF EXISTS
Many (but not all) DDL statements use
I forgot DROP POLICY already has IF EXISTS
From: Paul Austin
Sent: October 20, 2025 2:46 PM
To: [email protected]
Subject: Extend CREATE POLICY to add IF EXISTS
Many (but not all) DDL statements use the pattern IF EXISTS or IF NOT EXISTS.
This is really useful if you want to cr
Many (but not all) DDL statements use the pattern IF EXISTS or IF NOT EXISTS.
This is really useful if you want to create a re-start-able data model update
script without needing to have PL/pgSQL blocks that has checks to see if it
exists.
An example of a statement that doesn't implement this p
> On 20 Oct 2025, at 17:06, Rich Shepard wrote:
>
> On Mon, 20 Oct 2025, Michał Kłeczek wrote:
>
>> Do you have any means to make sure you didn’t enter the same number for
>> two different companies then?
>
> Michal,
>
> Yes. New companies are added one-at-a-time. In the 28 years I've used
On Mon, 20 Oct 2025, Michał Kłeczek wrote:
Do you have any means to make sure you didn’t enter the same number for
two different companies then?
Michal,
Yes. New companies are added one-at-a-time. In the 28 years I've used
postgres I've not had any such issues.
Regards,
Rich
> On 20 Oct 2025, at 16:26, Rich Shepard wrote:
>
> On Mon, 20 Oct 2025, Michał Kłeczek wrote:
>
>> How do you make sure a phone number is not shared by two (or more)
>> customers?
>
> Michal,
>
> If it's the company's main telephone number then it's shared by all
> employees with phones o
> On Oct 20, 2025, at 8:42 AM, Adrian Klaver wrote:
>
> On 10/20/25 07:07, Rich Shepard wrote:
>>> On Mon, 20 Oct 2025, Michał Kłeczek wrote:
>>> There is also another concern - do you want to make sure phone numbers are
>>> not shared?
>> Michal,
>> Shared with whom? I run a solo professiona
On 10/20/25 07:07, Rich Shepard wrote:
On Mon, 20 Oct 2025, Michał Kłeczek wrote:
There is also another concern - do you want to make sure phone numbers
are
not shared?
Michal,
Shared with whom? I run a solo professional services consultancy so there's
only me here the database.
That is t
On Mon, 20 Oct 2025, Ron Johnson wrote:
Multiple contacts at the same client company. If, for whatever reason, the
phone number changes you've got to update X rows in your contacts table,
whereas only one row needs to be updated when the schema meets 1NF. This
eliminates update anomalies.
Ron,
On Mon, 20 Oct 2025, Michał Kłeczek wrote:
How do you make sure a phone number is not shared by two (or more)
customers?
Michal,
If it's the company's main telephone number then it's shared by all
employees with phones on their desks. If it's a direct number then it
connects to only a single
On Mon, Oct 20, 2025 at 10:07 AM Rich Shepard
wrote:
> On Mon, 20 Oct 2025, Michał Kłeczek wrote:
>
> > There is also another concern - do you want to make sure phone numbers
> are
> > not shared?
>
> Michal,
>
> Shared with whom? I run a solo professional services consultancy so there's
> only m
> On 20 Oct 2025, at 16:07, Rich Shepard wrote:
>
> On Mon, 20 Oct 2025, Michał Kłeczek wrote:
>
>> There is also another concern - do you want to make sure phone numbers are
>> not shared?
>
> Michal,
>
> Shared with whom?
Sorry, I wasn’t clear.
How do you make sure a phone number is not
On Mon, 20 Oct 2025, Michał Kłeczek wrote:
There is also another concern - do you want to make sure phone numbers are
not shared?
Michal,
Shared with whom? I run a solo professional services consultancy so there's
only me here the database.
Rich
> On 20 Oct 2025, at 14:55, Rich Shepard wrote:
>
> On Mon, 20 Oct 2025, Peter J. Holzer wrote:
>
>> * Simplicity: If a set of values is always fetched together and updated
>> together, you might as well treat it as a unit and not split it over
>> multiple tables
>
>> The second may be releva
> On Oct 20, 2025, at 6:58 AM, Rich Shepard wrote:
>
> On Mon, 20 Oct 2025, Rob Sargent wrote:
>
>>> Okay. Now I'm curious: why do you write this?
>
>> The way I read your description of how you use these columns currently
>> suggests to me that they could be handled by a single timestamp c
On Mon, Oct 20, 2025 at 8:58 AM Rich Shepard
wrote:
> On Mon, 20 Oct 2025, Rob Sargent wrote:
>
> >> Okay. Now I'm curious: why do you write this?
>
> > The way I read your description of how you use these columns currently
> > suggests to me that they could be handled by a single timestamp colum
On Mon, 20 Oct 2025, Rob Sargent wrote:
Okay. Now I'm curious: why do you write this?
The way I read your description of how you use these columns currently
suggests to me that they could be handled by a single timestamp column.
The cost/benefit of converting is another thing altogether.
Ro
On Mon, 20 Oct 2025, Peter J. Holzer wrote:
* Simplicity: If a set of values is always fetched together and updated
together, you might as well treat it as a unit and not split it over
multiple tables
The second may be relevant for you. If you always display and edit the
phone numbers of a
> On Oct 20, 2025, at 6:45 AM, Rich Shepard wrote:
>
> On Sun, 19 Oct 2025, Rob Sargent wrote:
>
>> Definitely a datetime (single value) problem, imho
>
> Rob,
>
> Okay. Now I'm curious: why do you write this?
>
> Thanks,
>
> Rich
>
The way I read your description of how you use these
On Mon, 20 Oct 2025, Rob Sargent wrote:
I don’t see any mention of the current data types of the two columns
currently in play. apologies of I missed that.
Column| Type | Collation | Nullable | Default
--++---+-
On Sun, 19 Oct 2025, Rob Sargent wrote:
Definitely a datetime (single value) problem, imho
Rob,
Okay. Now I'm curious: why do you write this?
Thanks,
Rich
> On Oct 20, 2025, at 5:05 AM, Peter J. Holzer wrote:
>
> On 2025-10-19 20:32:07 -0600, Rob Sargent wrote:
On Oct 19, 2025, at 2:38 PM, Rich Shepard wrote:
>>> On Sun, 19 Oct 2025, Rob Sargent wrote:
I think you have to ask why those values were separated in the first
place. F
On 2025-10-19 13:43:09 -0700, Rich Shepard wrote:
> Now I'm slowly cleaning up my business tracking database using features not
> available way back when I developed it. That's why I ask questions that must
> seem obvious to all of you who work with postgres everyday and have for
> years. I'm readi
On 2025-10-19 20:32:07 -0600, Rob Sargent wrote:
> > On Oct 19, 2025, at 2:38 PM, Rich Shepard wrote:
> > On Sun, 19 Oct 2025, Rob Sargent wrote:
> >> I think you have to ask why those values were separated in the first
> >> place. For instance if they are thought of as a pair in most queries then
25 matches
Mail list logo
