On Thu, 28 Apr 2022 at 15:09, Peter Eisentraut
wrote:
>
> On 22.04.22 16:14, Tom Lane wrote:
> > That analogy would be compelling if exclusion constraints were a
> > SQL-standard feature; but they aren't so their clause syntax is
> > fully under our control. The scenario that worries me is that
>
On 22.04.22 16:14, Tom Lane wrote:
That analogy would be compelling if exclusion constraints were a
SQL-standard feature; but they aren't so their clause syntax is
fully under our control. The scenario that worries me is that
somewhere down the pike, the SQL committee might extend the
syntax of
Peter Eisentraut writes:
> On 21.04.22 13:43, Simon Riggs wrote:
>> Can you explain what you find unattractive about it?
> Well, if I want to create a table with a primary key, the established
> way is to say "primary key", not to have to assemble it from multiple
> pieces.
> I think this case
On 21.04.22 13:43, Simon Riggs wrote:
1. create the table without primary key
2. create the index
3. attach the index as primary key constraint
That doesn't sound attractive.
Can you explain what you find unattractive about it?
Well, if I want to create a table with a primary key, the establi
On Wed, 20 Apr 2022 at 21:46, Peter Eisentraut
wrote:
>
> On 18.04.22 22:48, Tom Lane wrote:
> >> Why not just get rid of the limitation that constraint definitions don't
> >> support non-default methods?
> > That approach would be doubling down on the assumption that we can always
> > shoehorn mo
On 18.04.22 22:48, Tom Lane wrote:
Why not just get rid of the limitation that constraint definitions don't
support non-default methods?
That approach would be doubling down on the assumption that we can always
shoehorn more custom options into SQL-standard constraint clauses, and
we'll never fa
On Wed, 20 Apr 2022 at 03:05, David G. Johnston
wrote:
> https://www.postgresql.org/docs/current/sql-altertable.html
> ADD table_constraint_using_index
> ...This form is not currently supported on partitioned tables.
Good to know, thanks very much for pointing it out.
That needs to be fixed bef
On Tue, Apr 19, 2022 at 9:14 AM Simon Riggs
wrote:
> On Mon, 18 Apr 2022 at 22:05, Simon Riggs
> wrote:
> >
> > On Mon, 18 Apr 2022 at 21:48, Tom Lane wrote:
> > >
> > > "David G. Johnston" writes:
> > > > On Mon, Apr 18, 2022 at 1:00 PM Simon Riggs <
> simon.ri...@enterprisedb.com>
> > > > wr
On Mon, 18 Apr 2022 at 22:05, Simon Riggs wrote:
>
> On Mon, 18 Apr 2022 at 21:48, Tom Lane wrote:
> >
> > "David G. Johnston" writes:
> > > On Mon, Apr 18, 2022 at 1:00 PM Simon Riggs
> > > wrote:
> > >> I propose that we change pg_dump so that when it creates a PK it does
> > >> so in 2 comma
On Mon, 18 Apr 2022 at 21:48, Tom Lane wrote:
>
> "David G. Johnston" writes:
> > On Mon, Apr 18, 2022 at 1:00 PM Simon Riggs
> > wrote:
> >> I propose that we change pg_dump so that when it creates a PK it does
> >> so in 2 commands:
> >> 1. CREATE [UNIQUE] INDEX iname ...
> >> 2. ALTER TABLE .
On Mon, Apr 18, 2022 at 1:48 PM Tom Lane wrote:
> "David G. Johnston" writes:
> > On Mon, Apr 18, 2022 at 1:00 PM Simon Riggs <
> simon.ri...@enterprisedb.com>
> > wrote:
> >> I propose that we change pg_dump so that when it creates a PK it does
> >> so in 2 commands:
> >> 1. CREATE [UNIQUE] IND
"David G. Johnston" writes:
> On Mon, Apr 18, 2022 at 1:00 PM Simon Riggs
> wrote:
>> I propose that we change pg_dump so that when it creates a PK it does
>> so in 2 commands:
>> 1. CREATE [UNIQUE] INDEX iname ...
>> 2. ALTER TABLE .. ADD PRIMARY KEY USING INDEX iname;
> Why not just get rid of
Simon Riggs writes:
> I propose that we change pg_dump so that when it creates a PK it does
> so in 2 commands:
> 1. CREATE [UNIQUE] INDEX iname ...
> 2. ALTER TABLE .. ADD PRIMARY KEY USING INDEX iname;
> Step
> (1) recreates the index, respecting its AM, even if that is not a btree
> (2) works
On Mon, Apr 18, 2022 at 1:00 PM Simon Riggs
wrote:
> At the moment you cannot create a unique index other than a btree. (As
> discussed on other threads, I am pursuing unique hash indexes for
> PostgreSQL, one step at a time).
> You get "ERROR index foo_idx is not a btree"
>
> According to parse_
14 matches
Mail list logo
