From: Albe Laurenz laurenz.a...@wien.gv.at
In a way, it is similar to using the data type serial. The column will be
displayed as integer, and the information that it was a serial can
only be inferred from the DEFAULT value.
It seems that this is working fine and does not cause many problems,
so
From: Albe Laurenz laurenz.a...@wien.gv.at
In a way, it is similar to using the data type serial. The column will be
displayed as integer, and the information that it was a serial can
only be inferred from the DEFAULT value.
It seems that this is working fine and does not cause many problems,
so
hi
This is nagaraj, while i am doing the maintenance of the database i am
facing this problem, after this error it will stop and i am not able to
take backup of the database.
ERROR: could not read block 984505 in file base/16393/2850139.7: read
only 4096 of 8192 bytes
Please help me to solve
On 2013-11-09 20:16:20 -0500, Steve Singer wrote:
When I try the test_decoding plugin on UPDATE I get rows like:
table do_inventory: UPDATE: ii_id[int8]:251 ii_in_stock[int8]:1
ii_reserved[int8]:144 ii_total_sold[int8]:911
which I think is only data from the new tuple.The lack of
Hi,
On 2013-11-10 20:07:41 +0530, Nagaraj Shindagi wrote:
This is nagaraj, while i am doing the maintenance of the database i am
facing this problem, after this error it will stop and i am not able to
take backup of the database.
What do you mean with it will stop? You should still be able
MauMau maumau...@gmail.com writes:
On the other hand, nchar is an established data type in the SQL standard. I
think most people will expect to get nchar as output from psql \d and
pg_dump as they specified in DDL.
This argument seems awfully weak. You've been able to say
create table
Jim Nasby j...@nasby.net writes:
On 10/3/13 12:49 PM, Magnus Hagander wrote:
We could also use git receive hooks, but those would be very hard to
override when you*do* need to modify the files (which you might
within a release).
You can have the receive hook ignore the condition on
[ back from vacation and slowly catching up on email ]
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Robert Haas robertmh...@gmail.com writes:
I think we were going to try to group the extensions into categories
(debugging tools, demonstration code, data types, etc.) and maybe
encourage
On 11/10/2013 09:41 AM, Andres Freund wrote:
Still give me the following:
update disorder.do_inventory set ii_in_stock=2 where ii_id=251;
UPDATE 1
test1=# LOG: tuple in table with oid: 35122 without primary key
Hm. Could it be that you still have an older test_decoding plugin
lying around? The
Peter Eisentraut pete...@gmx.net writes:
On 10/11/13 3:57 AM, Tom Lane wrote:
What about unused_oids?
We are not planning to put unused_oids in to the main build path, so
there is much less of a need to make it more portable or robust.
Also, as we have just (re-)learned, you cannot rely on
On Sun, Nov 10, 2013 at 1:07 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'd argue the opposite --- the existing shell-script version is entirely
useless to developers running on Windows, while they could use a Perl
version. Also, we've pretty much locked in the assumption that developers
will
[ catching up on old email ]
Andres Freund and...@2ndquadrant.com writes:
On 2013-10-15 00:23:15 +0200, Tomas Vondra wrote:
On 2013-10-10 12:54:23 -0400, Andrew Dunstan wrote:
This thread seems to have gone cold, but I'm inclined to agree with
Pavel. If the table doesn't exist, neither does
On 11/10/2013 04:16 PM, Peter Geoghegan wrote:
On Sun, Nov 10, 2013 at 1:07 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'd argue the opposite --- the existing shell-script version is entirely
useless to developers running on Windows, while they could use a Perl
version. Also, we've pretty much
On 2013-11-10 16:28:27 -0500, Tom Lane wrote:
[ catching up on old email ]
Andres Freund and...@2ndquadrant.com writes:
On 2013-10-15 00:23:15 +0200, Tomas Vondra wrote:
On 2013-10-10 12:54:23 -0400, Andrew Dunstan wrote:
This thread seems to have gone cold, but I'm inclined to agree
Andrew Dunstan and...@dunslane.net writes:
It might be a bit more portable if we replaced the shebang lines on perl
scripts with
#!/bin/env perl
Perhaps, if we're worried about people keeping perl somewhere other
than /usr/bin. However, the most likely reason for having a
Andres Freund and...@2ndquadrant.com writes:
On 2013-11-10 16:28:27 -0500, Tom Lane wrote:
I think this is nonsense. It's only one step removed from why do you
need IF EXISTS at all, you should know whether the object is there.
The entire point of this syntax is to not need to do detailed
On 2013-11-10 18:16:16 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2013-11-10 16:28:27 -0500, Tom Lane wrote:
I think this is nonsense. It's only one step removed from why do you
need IF EXISTS at all, you should know whether the object is there.
The entire
Andres Freund and...@2ndquadrant.com writes:
On 2013-11-10 18:16:16 -0500, Tom Lane wrote:
Then I take it you also think we should undo the changes that made
DROP TABLE IF EXISTS foo.bar not fail if schema foo doesn't exist?
Because after all, the schema is not the object being dropped.
No,
On 2013-11-10 18:26:26 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2013-11-10 18:16:16 -0500, Tom Lane wrote:
Then I take it you also think we should undo the changes that made
DROP TABLE IF EXISTS foo.bar not fail if schema foo doesn't exist?
Because after all,
Andres Freund and...@2ndquadrant.com writes:
... So we'd get approximately one line further unless we fix this for DROP
DEFAULT and DROP CONSTRAINT as well.
True. As far as pg_dump --clean is concerned, it'd undoubtedly be easier
if we did what you suggest and just eliminate the emitted DROP
On 2013-11-10 18:42:11 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
... So we'd get approximately one line further unless we fix this for DROP
DEFAULT and DROP CONSTRAINT as well.
Turns out that's bogus - ALTER TABLE has two levels of NOT EXISTS.
Maybe we should just
Like your customer, this bug has blown up my standby servers, twice in the
last month: the first time all 4 replicas, the second time (mysteriously
but luckily) only 1 of them.
At any rate, since the fix isn't available yet, is/are there any
configuration changes that can be made or maintenance
Hi,
On 2013-11-10 17:40:31 -0700, Noah Yetter wrote:
Like your customer, this bug has blown up my standby servers, twice in the
last month: the first time all 4 replicas, the second time (mysteriously
but luckily) only 1 of them.
At any rate, since the fix isn't available yet, is/are there
We had a complaint
http://www.postgresql.org/message-id/e1vjuby-0002a1...@wrigleys.postgresql.org
about the fact that 9.3 rejects queries with duplicate table aliases like
this:
select * from tenk1 a left join (int4_tbl a cross join int8_tbl b) c on unique1
= f1;
ERROR: table name a specified
Andres Freund and...@2ndquadrant.com writes:
Turns out that's bogus - ALTER TABLE has two levels of NOT EXISTS.
Maybe we should just do the same for DROP TRIGGER?
DROP TRIGGER [ IF EXISTS ] name ON table_name [ IF EXISTS ] [ CASCADE |
RESTRICT ]
Works for me.
Greg Stark st...@mit.edu writes:
The commit below, specifically the change mentioned in the last paragraph
to fix isLockedRel broke the following comment in addRangeTableEntry:
* If pstate is NULL, we just build an RTE and return it without adding it
* to an rtable list.
In fact
Hi Amit,
I have uploaded your patch for next commit fest, hope you can support
it if there is any feedback for your patch by reviewer/committer.
Thanks! Okay, I will support you.
Best Regards,
Naoya
Hi Naoya,
On Thu, Oct 31, 2013 at 5:42 PM, Robert Haas robertmh...@gmail.com wrote:
On
Hi all
I'm thinking about a possible solution for one of the row-security
issues - the ability of a malicious user to write a row-security policy
containing a malicious predicate function, then trick another user into
ttSELECT/tting from the table and running the function.
What about running the
28 matches
Mail list logo
