On 2017/10/18 20:37, Alvaro Herrera wrote:
> Amit Langote wrote:
>> Hi.
>>
>> Noticed that a alter table sub-command's name in Description (where it's
>> OWNER) differs from that in synopsis (where it's OWNER TO). Attached
>> patch to make them match, if the difference is unintentional.
>
> I agr
Amit Langote wrote:
> Hi.
>
> Noticed that a alter table sub-command's name in Description (where it's
> OWNER) differs from that in synopsis (where it's OWNER TO). Attached
> patch to make them match, if the difference is unintentional.
I agree -- pushed.
This paragraph
The actions fo
Hi.
Noticed that a alter table sub-command's name in Description (where it's
OWNER) differs from that in synopsis (where it's OWNER TO). Attached
patch to make them match, if the difference is unintentional.
Thanks,
Amit
diff --git a/doc/src/sgml/ref/alter_table.sgml
b/doc/src/sgml/ref/alter_ta
Rajkumar Raghuwanshi writes:
> I have created a table with primary key, and then dropped primary key from
> table. But table still have not null constraint added by primary key.
> Is there any other statement to delete primary key with not null?
> or this is an expected behaviour of pg?
Yes, it'
On Thu, May 11, 2017 at 3:03 PM, Rajkumar Raghuwanshi
wrote:
> Hi All,
>
> I have created a table with primary key, and then dropped primary key from
> table. But table still have not null constraint added by primary key.
>
> Is there any other statement to delete primary key with not null?
> or t
Hi All,
I have created a table with primary key, and then dropped primary key from
table. But table still have not null constraint added by primary key.
Is there any other statement to delete primary key with not null?
or this is an expected behaviour of pg?
postgres=# create table tbl (c1 int p
Tom Lane wrote:
> Alvaro Herrera writes:
> > Tom Lane wrote:
> >> [ pokes around... ] The code I was thinking of is convert_tuples_by_name
> >> in access/common/tupconvert.c. There's a bit of an API mismatch in that
> >> it wants to wrap the mapping array in a TupleConversionMap struct; but
> >>
Alvaro Herrera writes:
> Tom Lane wrote:
>> [ pokes around... ] The code I was thinking of is convert_tuples_by_name
>> in access/common/tupconvert.c. There's a bit of an API mismatch in that
>> it wants to wrap the mapping array in a TupleConversionMap struct; but
>> maybe we could refactor tup
Tom Lane wrote:
> Alvaro Herrera writes:
> > Tom Lane wrote:
> >> Hmm. The bespoke code for constructing the attno map bothers me;
> >> surely there is existing code that does that? If not, it'd still
> >> make more sense to factor it out, I think, because there will be
> >> other needs for it i
Alvaro Herrera writes:
> Tom Lane wrote:
>> Hmm. The bespoke code for constructing the attno map bothers me;
>> surely there is existing code that does that? If not, it'd still
>> make more sense to factor it out, I think, because there will be
>> other needs for it in future.
> There isn't any
Tom Lane wrote:
> Alvaro Herrera writes:
> > Alvaro Herrera wrote:
> >> Here's a first attempt at fixing this. It makes the test pass, but I
> >> have the feeling that more complex ones might need more work.
>
> > Here's another one with three main differences:
>
> Hmm. The bespoke code for co
Alvaro Herrera writes:
> Alvaro Herrera wrote:
>> Here's a first attempt at fixing this. It makes the test pass, but I
>> have the feeling that more complex ones might need more work.
> Here's another one with three main differences:
Hmm. The bespoke code for constructing the attno map bothers
Alvaro Herrera wrote:
> Tom Lane wrote:
>
> > We could probably fix the specific issue being seen here by passing the
> > expression tree through a suitable attno remapping,
>
> Here's a first attempt at fixing this. It makes the test pass, but I
> have the feeling that more complex ones might n
Tom Lane wrote:
> We could probably fix the specific issue being seen here by passing the
> expression tree through a suitable attno remapping,
Here's a first attempt at fixing this. It makes the test pass, but I
have the feeling that more complex ones might need more work. Have to
leave for a
On 2017/01/05 8:05, Tom Lane wrote:
> Ashutosh Bapat writes:
>> Right. But I think it's better to use attribute id, in case the code
>> raising this error changes for any reason in future.
>
> I agree. The parent's "tdhasoid" flag is definitely based on the
> existence of an ObjectIdAttributeNum
>
>> The code updating attinhcount and then updating the catalogs is same
>> for user defined attributes and OID. Should we separate it out into a
>> function and use that function instead of duplicating the code?
>
> Didn't really seem worth the trouble ... maybe if it gets any longer
> it'd be ap
Ashutosh Bapat writes:
> Right. But I think it's better to use attribute id, in case the code
> raising this error changes for any reason in future.
I agree. The parent's "tdhasoid" flag is definitely based on the
existence of an ObjectIdAttributeNumber system column, not on whether the
column's
Tom Lane wrote:
> A little bit of "git bisect"-ing later, the blame is pinned on
>
> commit 9550e8348b7965715789089555bb5a3fda8c269c
> Author: Alvaro Herrera
> Date: Fri Apr 3 17:33:05 2015 -0300
>
> Transform ALTER TABLE/SET TYPE/USING expr during parse analysis
>
> This lets la
I wrote:
> Hah:
> regression=# create table p(f1 int);
> CREATE TABLE
> regression=# create table c1(extra smallint) inherits(p);
> CREATE TABLE
> regression=# alter table p add column f2 int;
> ALTER TABLE
> regression=# insert into c1 values(1,2,3);
> INSERT 0 1
> regression=# alter table p alte
Justin Pryzby writes:
> On Tue, Jan 03, 2017 at 03:35:34PM -0500, Tom Lane wrote:
>> Right. So I bet that if you check the attnum of pmsumpacketlatency_000 in
>> eric_umts_rnc_utrancell_metrics, you'll find it's different from that in
>> eric_umts_rnc_utrancell_201701, and that the attribute havi
On Tue, Jan 03, 2017 at 03:35:34PM -0500, Tom Lane wrote:
> Justin Pryzby writes:
> > On Tue, Jan 03, 2017 at 03:18:15PM -0500, Tom Lane wrote:
> >> I'm wondering if this represents some sort of out-of-sync condition
> >> between the table and its child tables. We can't actually tell from
> >> th
Justin Pryzby writes:
> On Tue, Jan 03, 2017 at 03:18:15PM -0500, Tom Lane wrote:
>> I'm wondering if this represents some sort of out-of-sync condition
>> between the table and its child tables. We can't actually tell from
>> this trace which table is being processed. Could you try, from this
>
On Tue, Jan 03, 2017 at 03:18:15PM -0500, Tom Lane wrote:
> Justin Pryzby writes:
> > (gdb) bt
> > #3 0x0059d5ce in ATRewriteTable (tab=,
> > OIDNewHeap=, lockmode=) at
> > tablecmds.c:4152
>
> I'm wondering if this represents some sort of out-of-sync condition
> between the table and
I wrote:
> I'm wondering if this represents some sort of out-of-sync condition
> between the table and its child tables.
Hah:
regression=# create table p(f1 int);
CREATE TABLE
regression=# create table c1(extra smallint) inherits(p);
CREATE TABLE
regression=# alter table p add column f2 int;
ALTE
Justin Pryzby writes:
> (gdb) bt
> #0 errfinish (dummy=0) at elog.c:414
> #1 0x005d0e30 in ExecEvalScalarVar (exprstate=,
> econtext=, isNull=, isDone= optimized out>) at execQual.c:655
> #2 0x005d0c3c in ExecMakeFunctionResultNoSets (fcache=0x21f18a0,
> econtext=0x2199e80, is
On Tue, Jan 03, 2017 at 02:50:21PM -0500, Tom Lane wrote:
> Justin Pryzby writes:
> > On Tue, Jan 03, 2017 at 02:32:36PM -0500, Tom Lane wrote:
> >> 2. Even better would be a stack trace for the call to errfinish,
> >> https://wiki.postgresql.org/wiki/Generating_a_stack_trace_of_a_PostgreSQL_backe
Justin Pryzby writes:
> On Tue, Jan 03, 2017 at 02:32:36PM -0500, Tom Lane wrote:
>> 2. Even better would be a stack trace for the call to errfinish,
>> https://wiki.postgresql.org/wiki/Generating_a_stack_trace_of_a_PostgreSQL_backend
Thanks, but we need the whole call stack, or at least the firs
On Tue, Jan 03, 2017 at 02:32:36PM -0500, Tom Lane wrote:
> 3. It's pretty hard to see how you'd reach any of these places for an
> ALTER COLUMN TYPE on a simple table. Has the table got rules, triggers,
> default values? Could we see "\d+" output for it?
I really meant to do \d+..
On Tue, Jan 03, 2017 at 02:32:36PM -0500, Tom Lane wrote:
> Justin Pryzby writes:
> I can cause the error at will on the existing table,
>
> That's good news, at least.
>
> 1. Please trigger it with "\set VERBOSITY verbose" enabled, so we can see
> the exact source location --- there are a
Justin Pryzby writes:
I can cause the error at will on the existing table,
That's good news, at least.
1. Please trigger it with "\set VERBOSITY verbose" enabled, so we can see
the exact source location --- there are a couple of instances of that
text.
2. Even better would be a stack trace
On Tue, Jan 03, 2017 at 01:40:50PM -0500, Robert Haas wrote:
> On Tue, Jan 3, 2017 at 11:59 AM, Justin Pryzby wrote:
> > On Tue, Jan 03, 2017 at 11:45:33AM -0500, Robert Haas wrote:
> >> > ts=# begin; drop view umts_eric_ch_switch_view,
> >> > eric_umts_rnc_utrancell_view, umts_eric_cell_integrit
On Tue, Jan 3, 2017 at 11:59 AM, Justin Pryzby wrote:
> On Tue, Jan 03, 2017 at 11:45:33AM -0500, Robert Haas wrote:
>> > ts=# begin; drop view umts_eric_ch_switch_view,
>> > eric_umts_rnc_utrancell_view, umts_eric_cell_integrity_view; ALTER TABLE
>> > eric_umts_rnc_utrancell_metrics ALTER COLUM
On Tue, Jan 03, 2017 at 11:45:33AM -0500, Robert Haas wrote:
> > ts=# begin; drop view umts_eric_ch_switch_view,
> > eric_umts_rnc_utrancell_view, umts_eric_cell_integrity_view; ALTER TABLE
> > eric_umts_rnc_utrancell_metrics ALTER COLUMN PMSUMPACKETLATENCY_000 TYPE
> > BIGINT USING PMSUMPACKETL
On Mon, Jan 2, 2017 at 7:32 PM, Justin Pryzby wrote:
> On Wed, Oct 12, 2016 at 10:25:05AM -0500, Justin Pryzby wrote:
>> > I don't have a clear recollection how I solved this in July; possibly by
>> > restoring the (historic, partition) table from backup.
>> >
>> > Last week again again just now (
On Wed, Oct 12, 2016 at 10:25:05AM -0500, Justin Pryzby wrote:
> > I don't have a clear recollection how I solved this in July; possibly by
> > restoring the (historic, partition) table from backup.
> >
> > Last week again again just now (both under 9.6), a colleague found that he
> > was
> > abl
I originally sent to psql-general some months ago, but it appears it was never
delivered (perhaps I wasn't properly subscribed?).
Failed to alter table eric_umts_rnc_utrancell_metrics: ERROR: attribute 361
has wrong type
DETAIL: Table has type integer, but query expects smallint.
We've seen th
>>
>> We allow creating user attribute with name "oid" so you do not want to
>> search system attribute oid by name. Instead search by attribute id
>> ObjectIdAttributeNumber.
>
> Good point. Although, there can only be one of the two in a table at any
> given time - either the "oid" system column
On 2016/12/27 22:24, Ashutosh Bapat wrote:
> On Mon, Dec 26, 2016 at 3:36 PM, Amit Langote
> wrote:
>> Attached patches modifies MergeAttributesIntoExisting() such that we
>> increment attinhcount not only for user attributes, but also for the oid
>> system column if one exists.
>>
>> Thoughts?
>
On Mon, Dec 26, 2016 at 3:36 PM, Amit Langote
wrote:
> I suspect the following is a bug:
>
> create table foo (a int) with oids;
> CREATE TABLE
> create table bar (a int);
> CREATE TABLE
> alter table bar inherit foo;
> ERROR: table "bar" without OIDs cannot inherit from table "foo" with OIDs
>
>
On 2016/12/26 19:06, Amit Langote wrote:
> I suspect the following is a bug:
A better subject line could be: "ALTER TABLE INHERIT and the oid column"
Thanks,
Amit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql
I suspect the following is a bug:
create table foo (a int) with oids;
CREATE TABLE
create table bar (a int);
CREATE TABLE
alter table bar inherit foo;
ERROR: table "bar" without OIDs cannot inherit from table "foo" with OIDs
alter table bar set with oids;
ALTER TABLE
alter table bar inherit foo;
Robert Haas writes:
> On Tue, May 10, 2016 at 11:22 PM, Tom Lane wrote:
>> You should look at the code in ALTER TABLE that tries to rebuild index
>> definitions during ALTER COLUMN TYPE, and see if that can be adapted
>> to updating views.
> I think the problems are almost entirely different. I
On Tue, May 10, 2016 at 11:22 PM, Tom Lane wrote:
> You should look at the code in ALTER TABLE that tries to rebuild index
> definitions during ALTER COLUMN TYPE, and see if that can be adapted
> to updating views.
I think the problems are almost entirely different. In the case of
ALTER TABLE, w
Peter Eisentraut wrote:
> On 5/3/16 1:25 PM, Alvaro Herrera wrote:
> >If we can put together a script that runs test.sh for various versions
> >and then verifies the runs, we could use it in both buildfarm and
> >coverage.
>
> Not that that would be useless, but note that the value in this case (a
On Wed, May 11, 2016 at 09:40:09AM -0400, Peter Eisentraut wrote:
> Not that that would be useless, but note that the value in this case (and
> most others) comes from having a candidate object in the database before
> upgrade that exercises the particular problem, mostly independent of what
> vers
On 5/3/16 1:25 PM, Alvaro Herrera wrote:
If we can put together a script that runs test.sh for various versions
and then verifies the runs, we could use it in both buildfarm and
coverage.
Not that that would be useless, but note that the value in this case
(and most others) comes from having a
Euler Taveira writes:
> On 10-05-2016 20:59, Rob Bygrave wrote:
>> Having read all the previous discussions on the general topic of
>> altering tables with dependent views I realise this is a complex and
>> difficult issue in general but I'd like to see if there was some support
>> for looking at
On 10-05-2016 20:59, Rob Bygrave wrote:
> Having read all the previous discussions on the general topic of
> altering tables with dependent views I realise this is a complex and
> difficult issue in general but I'd like to see if there was some support
> for looking at these 3 more specific changes
On Fri, May 6, 2016 at 03:32:23PM -0400, Tom Lane wrote:
> > I think possibly the easiest fix for this is to have pg_upgrade,
> > instead of RESETting a nonexistent option, RESET something that's
> > still considered to require AccessExclusiveLock. "user_catalog_table"
> > would work, looks like;
On Tue, May 3, 2016 at 12:07:51PM -0400, Tom Lane wrote:
> I think possibly the easiest fix for this is to have pg_upgrade,
> instead of RESETting a nonexistent option, RESET something that's
> still considered to require AccessExclusiveLock. "user_catalog_table"
> would work, looks like; though
I have read the prior discussions linked from
https://wiki.postgresql.org/wiki/Todo#Views_and_Rules
What I would like to do is put the specific case for handling 3 common
'alter column' changes when that column is referenced in a view.
Take the case of:
create table base_table ( id bigserial, ac
For what it's worth, for my historical sort benchmarks I got Postgres
to build right back to 6.5 using modern tools. I have patches if
anyone wants them. Pre-7.3 doesn't actually run because we didn't
support 64-bit architectures before Tom did the V1 api (there was a
set of Alpha patches floating
On 7 May 2016 at 16:49, Tom Lane wrote:
> Simon Riggs writes:
> > On 3 May 2016 at 18:07, Tom Lane wrote:
> >> Or at least, it did until Simon decided that ALTER TABLE RESET
> >> doesn't require AccessExclusiveLock.
>
> > On reflection, this still seems like a good idea.
>
> Yes, what pg_upgrad
Simon Riggs writes:
> On 3 May 2016 at 18:07, Tom Lane wrote:
>> Or at least, it did until Simon decided that ALTER TABLE RESET
>> doesn't require AccessExclusiveLock.
> On reflection, this still seems like a good idea.
Yes, what pg_upgrade was doing was clearly a hack, and not a very nice one.
On 3 May 2016 at 18:07, Tom Lane wrote:
> Or at least, it did until Simon decided that ALTER TABLE RESET
> doesn't require AccessExclusiveLock.
On reflection, this still seems like a good idea.
> Now you get a failure.
>
Failure condition as an exception to that.
> I haven't tried to cons
I wrote:
> I have no more time to work on this, but I think it needs to be fixed, and
> I definitely think we had better put in test coverage when we do fix it.
Actually, there is a really easy fix we could put in, which is to decide
that optionally_create_toast_tables() is useless and get rid of
I wrote:
> I haven't tried to construct a pre-9.1 database that would trigger
> this, but you can make it happen by applying the attached patch
> to create a toast-table-less table in the regression tests,
> and then doing "make check" in src/bin/pg_upgrade. You get this:
> ...
> Restoring databa
On 05/03/2016 01:58 PM, Alvaro Herrera wrote:
Andrew Dunstan wrote:
And if this is of any use, here are the dump differences from every live
version to git tip, as of this morning.
Interesting, thanks. I wonder if some of these diffs could be reduced
further by using pg_dump -Fd instead of
Andres Freund writes:
> On 2016-05-03 12:07:51 -0400, Tom Lane wrote:
>> I think possibly the easiest fix for this is to have pg_upgrade,
>> instead of RESETting a nonexistent option, RESET something that's
>> still considered to require AccessExclusiveLock. "user_catalog_table"
>> would work, lo
On 2016-05-03 13:47:14 -0400, Tom Lane wrote:
> I've been thinking of proposing that it's time (not now, at this point,
> but for 9.7) to rip out libpq's support for V2 protocol as well as
> pg_dump's support for pre-7.4 backends.
+1
> There might be an argument for moving pg_dump's cutoff furth
Andrew Dunstan wrote:
> And if this is of any use, here are the dump differences from every live
> version to git tip, as of this morning.
Interesting, thanks. I wonder if some of these diffs could be reduced
further by using pg_dump -Fd instead of a single text dump -- then
internal ordering wo
* Andres Freund (and...@anarazel.de) wrote:
> On 2016-05-03 12:07:51 -0400, Tom Lane wrote:
> > I think possibly the easiest fix for this is to have pg_upgrade,
> > instead of RESETting a nonexistent option, RESET something that's
> > still considered to require AccessExclusiveLock. "user_catalog_
Stephen Frost writes:
> One other point is that pg_dump goes quite a bit farther back than just
> what we currently support (or at least, it tries to). I think that,
> generally, that's a good thing, but it does mean we have a lot of cases
> that don't get tested nearly as much...
Yeah. I do pe
Hi,
On 2016-05-03 12:07:51 -0400, Tom Lane wrote:
> I think possibly the easiest fix for this is to have pg_upgrade,
> instead of RESETting a nonexistent option, RESET something that's
> still considered to require AccessExclusiveLock. "user_catalog_table"
> would work, looks like; though I'd wan
Stephen Frost wrote:
> One other point is that pg_dump goes quite a bit farther back than just
> what we currently support (or at least, it tries to). I think that,
> generally, that's a good thing, but it does mean we have a lot of cases
> that don't get tested nearly as much...
>
> I was able
On 05/03/2016 01:33 PM, Andrew Dunstan wrote:
On 05/03/2016 01:28 PM, Andrew Dunstan wrote:
On 05/03/2016 01:21 PM, Stephen Frost wrote:
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
Tom Lane wrote:
More generally, though, I wonder how we can have some test coverage
on such cases
On 05/03/2016 01:28 PM, Andrew Dunstan wrote:
On 05/03/2016 01:21 PM, Stephen Frost wrote:
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
Tom Lane wrote:
More generally, though, I wonder how we can have some test coverage
on such cases going forward. Is the patch below too ugly to co
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Stephen Frost wrote:
> > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> > > Tom Lane wrote:
> > >
> > > > More generally, though, I wonder how we can have some test coverage
> > > > on such cases going forward. Is the patch below too ugly
On 05/03/2016 01:21 PM, Stephen Frost wrote:
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
Tom Lane wrote:
More generally, though, I wonder how we can have some test coverage
on such cases going forward. Is the patch below too ugly to commit
permanently, and if so, what other idea can
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Tom Lane wrote:
>
> > More generally, though, I wonder how we can have some test coverage
> > on such cases going forward. Is the patch below too ugly to commit
> > permanently, and if so, what other idea can you suggest?
>
> I suggest a build
Stephen Frost wrote:
> * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> > Tom Lane wrote:
> >
> > > More generally, though, I wonder how we can have some test coverage
> > > on such cases going forward. Is the patch below too ugly to commit
> > > permanently, and if so, what other idea can yo
Tom Lane wrote:
> More generally, though, I wonder how we can have some test coverage
> on such cases going forward. Is the patch below too ugly to commit
> permanently, and if so, what other idea can you suggest?
I suggest a buildfarm animal running a custom buildfarm module that
exercises the
There is logic in pg_upgrade plus the backend, mostly added by commit
4c6780fd1, to cope with the corner cases that sometimes arise where the
old and new versions have different ideas about whether a given table
needs a TOAST table. The more common case is where there's a TOAST table
in the old DB
On 1/30/16 10:52 AM, Marko Tiikkaja wrote:
> On 2016-01-21 04:17, Simon Riggs wrote:
>> Marko, I was/am waiting for an updated patch. Could you comment please?
>
> Sorry, I've not found time to work on this recently.
>
> Thanks for everyone's comments so far. I'll move this to the next CF
> and
On 2016-01-21 04:17, Simon Riggs wrote:
Marko, I was/am waiting for an updated patch. Could you comment please?
Sorry, I've not found time to work on this recently.
Thanks for everyone's comments so far. I'll move this to the next CF
and try and get an updated patch done in time for that one
On 5 January 2016 at 06:45, Simon Riggs wrote:
> On 4 January 2016 at 20:44, Alvaro Herrera
> wrote:
>
>
>> Maybe
>> there are more ALTER TABLE subcommands that should be setting something
>> up? In cases where multiple subcommands are being run, it might be
>> useful to see which one caused a
On 4 January 2016 at 20:44, Alvaro Herrera wrote:
> Maybe
> there are more ALTER TABLE subcommands that should be setting something
> up? In cases where multiple subcommands are being run, it might be
> useful to see which one caused a certain error message.
>
I like the patch.
We should have
2016-01-04 21:44 GMT+01:00 Alvaro Herrera :
> Pavel Stehule wrote:
> > 2015-10-05 0:08 GMT+02:00 Marko Tiikkaja :
> >
> > > In the past I've found the error message in cases such as this somewhat
> > > less helpful than it could be:
> > >
> > > =# CREATE TABLE qqq (a int);
> > > =# CREATE UNIQUE I
Pavel Stehule wrote:
> 2015-10-05 0:08 GMT+02:00 Marko Tiikkaja :
>
> > In the past I've found the error message in cases such as this somewhat
> > less helpful than it could be:
> >
> > =# CREATE TABLE qqq (a int);
> > =# CREATE UNIQUE INDEX IF NOT EXISTS qqq_a_idx ON qqq(a);
> > =# ALTER TABLE q
2015-10-05 0:08 GMT+02:00 Marko Tiikkaja :
> Hi,
>
> In the past I've found the error message in cases such as this somewhat
> less helpful than it could be:
>
> =# CREATE TABLE qqq (a int);
> =# CREATE UNIQUE INDEX IF NOT EXISTS qqq_a_idx ON qqq(a);
> =# ALTER TABLE qqq ALTER COLUMN a TYPE json U
Hi,
In the past I've found the error message in cases such as this somewhat
less helpful than it could be:
=# CREATE TABLE qqq (a int);
=# CREATE UNIQUE INDEX IF NOT EXISTS qqq_a_idx ON qqq(a);
=# ALTER TABLE qqq ALTER COLUMN a TYPE json USING NULL;
ERROR: data type json has no default operat
On Fri, Aug 14, 2015 at 5:18 PM, Tom Lane wrote:
> Robert Haas writes:
>> Commit f14a6bbedb79adce2298d0d4f5e2abe8563e0eca added an isolation
>> test, alter-table-1.spec, which reads in part:
>
>> session "s2"
>> setup { BEGIN; }
>> step "rx1" { SELECT * FROM b WHERE a_id = 1 LIMIT
Robert Haas writes:
> Commit f14a6bbedb79adce2298d0d4f5e2abe8563e0eca added an isolation
> test, alter-table-1.spec, which reads in part:
> session "s2"
> setup { BEGIN; }
> step "rx1" { SELECT * FROM b WHERE a_id = 1 LIMIT 1; }
> step "wx" { INSERT INTO b VALUES (0); }
> ste
Commit f14a6bbedb79adce2298d0d4f5e2abe8563e0eca added an isolation
test, alter-table-1.spec, which reads in part:
session "s2"
setup { BEGIN; }
step "rx1" { SELECT * FROM b WHERE a_id = 1 LIMIT 1; }
step "wx" { INSERT INTO b VALUES (0); }
step "rx1" { SELECT * FROM b WHER
On Thu, Jul 23, 2015 at 9:06 AM, Michael Paquier
wrote:
> Yeah, I think we should be able to define a collation in this case.
> For example it is as well possible to pass a WITH clause with storage
> parameters, though we do not document it in
> table_constraint_using_index
> (http://www.postgresq
On Thu, Jul 23, 2015 at 5:47 AM, Gurjeet Singh wrote:
> On Wed, Jul 22, 2015 at 7:34 AM, Robert Haas wrote:
>>
>> On Tue, Jul 21, 2015 at 8:34 PM, Michael Paquier
>> wrote:
>> > On Wed, Jul 22, 2015 at 1:23 AM, Robert Haas
>> > wrote:
>> >> Notice that the collation specifier is gone. Oops.
>>
On Tue, Jul 21, 2015 at 9:23 AM, Robert Haas wrote:
> rhaas=# create unique index on foo (a collate "C");
> CREATE INDEX
> rhaas=# alter table foo add primary key using index foo_a_idx;
> ALTER TABLE
>
> Now dump and restore this database. Then:
>
> Notice that the collation specifier is gon
On Wed, Jul 22, 2015 at 7:34 AM, Robert Haas wrote:
> On Tue, Jul 21, 2015 at 8:34 PM, Michael Paquier
> wrote:
> > On Wed, Jul 22, 2015 at 1:23 AM, Robert Haas
> wrote:
> >> Notice that the collation specifier is gone. Oops.
> >
> > As it is not possible to specify directly a constraint for a
On Tue, Jul 21, 2015 at 8:34 PM, Michael Paquier
wrote:
> On Wed, Jul 22, 2015 at 1:23 AM, Robert Haas wrote:
>> Notice that the collation specifier is gone. Oops.
>
> As it is not possible to specify directly a constraint for a PRIMARY
> KEY expression, what about switching dumpConstraint to ha
On Wed, Jul 22, 2015 at 9:34 AM, Michael Paquier
wrote:
> On Wed, Jul 22, 2015 at 1:23 AM, Robert Haas wrote:
>> Notice that the collation specifier is gone. Oops.
>
> As it is not possible to specify directly a constraint for a PRIMARY
> KEY expression, what about switching dumpConstraint to ha
On Wed, Jul 22, 2015 at 1:23 AM, Robert Haas wrote:
> Notice that the collation specifier is gone. Oops.
As it is not possible to specify directly a constraint for a PRIMARY
KEY expression, what about switching dumpConstraint to have it use
first a CREATE INDEX query with the collation and then
Consider:
rhaas=# create table foo (a text);
CREATE TABLE
rhaas=# create unique index on foo (a collate "C");
CREATE INDEX
rhaas=# alter table foo add primary key using index foo_a_idx;
ALTER TABLE
rhaas=# \d foo
Table "public.foo"
Column | Type | Modifiers
+--+---
a
As part of the ALTER TABLE lock reductions we've now agreed that
reloptions should have a lock level associated with them, so we can
take appropriate lock levels.
Attached patch will be applied at start of 9.5 dev cycle, so that any
new relopt authors are aware that lock levels are needed for any
On 2/26/14, 9:15 AM, Simon Riggs wrote:
On 26 February 2014 13:38, Andres Freund wrote:
>Hi,
>
>On 2014-02-26 07:32:45 +, Simon Riggs wrote:
>> >* This definitely should include isolationtester tests actually
>> > performing concurrent ALTER TABLEs. All that's currently there is
>> > t
On 21 March 2014 16:11, Simon Riggs wrote:
>>> + * Be careful to ensure this function is called for Tables and Indexes
>>> only.
>>> + * It is not currently safe to be called for Views because security_barrier
>>> + * is listed as an option and so would be allowed to be set at a level
>>> lower
On 21 March 2014 23:36, Tom Lane wrote:
> Simon Riggs writes:
>> On 21 March 2014 20:58, Noah Misch wrote:
>>> It's not the behavior I would choose for a new product, but I can't see
>>> benefits sufficient to overturn previous decisions to keep it.
>
>> Speechless
>
> The key argument for not "
Simon Riggs writes:
> On 21 March 2014 20:58, Noah Misch wrote:
>> It's not the behavior I would choose for a new product, but I can't see
>> benefits sufficient to overturn previous decisions to keep it.
> Speechless
The key argument for not "fixing" this is that it would break existing
pg_dum
On 21 March 2014 20:58, Noah Misch wrote:
> On Fri, Mar 21, 2014 at 06:53:27PM +, Simon Riggs wrote:
>> On 21 March 2014 17:49, Noah Misch wrote:
>>
>> >> > alter table information_schema.triggers set (security_barrier = true);
>> >>
>> >> I find it hard to justify why we accept such a stat
On Fri, Mar 21, 2014 at 06:53:27PM +, Simon Riggs wrote:
> On 21 March 2014 17:49, Noah Misch wrote:
>
> >> > alter table information_schema.triggers set (security_barrier = true);
> >>
> >> I find it hard to justify why we accept such a statement. Surely its a
> >> bug when the named table
On 21 March 2014 03:45, Noah Misch wrote:
>> + * Note that Hot Standby only knows about AccessExclusiveLocks on the master
>> + * so any changes that might affect SELECTs running on standbys need to use
>> + * AccessExclusiveLocks even if you think a lesser lock would do, unless you
>> + * have a
1 - 100 of 848 matches
Mail list logo
