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
SELECTing from the table and running the function.
What about running the row-s
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 wrote:
> > On Thu, Oct 31, 201
Greg Stark 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 isLockedRefname()
Andres Freund 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.
regards, tom lane
--
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
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 th
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 pr
On 2013-11-10 18:42:11 -0500, Tom Lane wrote:
> Andres Freund 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 do the same for DR
Andres Freund 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 commands
for table com
On 2013-11-10 18:26:26 -0500, Tom Lane wrote:
> Andres Freund 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 sche
Andres Freund 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, not the same
On 2013-11-10 18:16:16 -0500, Tom Lane wrote:
> Andres Freund 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 thi
Andres Freund 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 analysis
>> about
Andrew Dunstan 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
/usr/local/bin/perl or whatever
On 2013-11-10 16:28:27 -0500, Tom Lane wrote:
> [ catching up on old email ]
>
> Andres Freund 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
> >>> Pav
On 11/10/2013 04:16 PM, Peter Geoghegan wrote:
On Sun, Nov 10, 2013 at 1:07 PM, Tom Lane 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 assumpt
[ catching up on old email ]
Andres Freund 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 the trigger, an
On Sun, Nov 10, 2013 at 1:07 PM, Tom Lane 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 have Perl.
+1.
-
Peter Eisentraut 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 /usr/bin/p
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? Th
[ back from vacation and slowly catching up on email ]
Dimitri Fontaine writes:
> Robert Haas writes:
>> I think we were going to try to group the extensions into categories
>> (debugging tools, demonstration code, data types, etc.) and maybe
>> encourage packagers to put the debugging tools in
Jim Nasby 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 existence of a
"MauMau" 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 nt (nf natio
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 ab
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.
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 sol
From: "Albe Laurenz"
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 I don't see why t
From: "Albe Laurenz"
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 I don't see why t
28 matches
Mail list logo
