On Mon, Oct 22, 2012 at 3:54 PM, Greg Stark wrote:
> We could go even further:
> INFO: Server identity "ACME Debian Machine" certified by "Snakeoil CA"
> WARNING: Server identity signed by unknown and untrusted authority "Snakeoil
> CA"
> HINT: Add either the server certificate or the CA certific
Kohei KaiGai writes:
> postgres=# CREATE TABLE t1 (x int, y text);
> CREATE TABLE
> postgres=# CREATE RULE "_RETURN" AS ON SELECT TO t1 DO INSTEAD SELECT
> 1 AS x, 'aaa'::text AS y;
> CREATE RULE
> postgres=# SELECT * FROM t1;
> x | y
> ---+-
> 1 | aaa
> (1 row)
> postgres=# SELECT table
On Wed, Oct 17, 2012 at 7:48 PM, Christopher Browne wrote:
> Well, replication is arguably a relevant case.
>
> For Slony, the origin/master node never cares about logged changes - that
> data is only processed on replicas. Now, that's certainly a little weaselly
> - the log data (sl_log_*) has g
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
> ow...@postgresql.org] On Behalf Of Merlin Moncure
> Sent: Monday, October 22, 2012 6:54 PM
> To: Robert Haas
> Cc: Andrew Dunstan; Josh Berkus; Daniel Farina; pgsql-
> hack...@postgresql.org
> Subject:
On Mon, Oct 22, 2012 at 4:57 PM, Tom Lane wrote:
> Don't hold your breath. There are two ways the system could implement
> the DISTINCT clause: either sort and uniq, or hashaggregate.
> hashaggregate will destroy any input ordering, so there's no value in
> using the index as input. sort and uni
On Sun, Oct 21, 2012 at 5:49 PM, Tom Lane wrote:
> Magnus Hagander writes:
>> I don't see a problem at all with providing the snakeoil cert. In
>> fact, it's quite useful.
>
>> I see a problem with enabling it by default. Because it makes people
>> think they are more secure than they are.
>
> I
On Fri, Oct 19, 2012 at 2:55 PM, Robert Haas wrote:
> On Fri, Oct 19, 2012 at 10:29 AM, Andrew Dunstan wrote:
>> As you can see, in the case of rewrite it takes us back 7 1/2 years. I know
>> this is a *very* rough measure, but it still tends to indicate to me that
>> the maintenance burden isn't
On Wed, Oct 10, 2012 at 4:24 PM, Marko Kreen wrote:
> The SCRAM looks good from the quick glance.
SCRAM does have weakness - the info necessary to log in
as client (ClientKey) is exposed during authentication
process.
IOW, the stored auth info can be used to log in as client,
if the attacker can
I could find out a case to cause Assert() failure during investigation of RLS...
postgres=# CREATE TABLE t1 (x int, y text);
CREATE TABLE
postgres=# CREATE RULE "_RETURN" AS ON SELECT TO t1 DO INSTEAD SELECT
1 AS x, 'aaa'::text AS y;
CREATE RULE
postgres=# SELECT * FROM t1;
x | y
---+-
1
2012/10/22 Robert Haas :
> On Thu, Oct 18, 2012 at 2:19 PM, Alvaro Herrera
> wrote:
>> Kohei KaiGai escribió:
>>> The revised patch fixes the problem that Daen pointed out.
>>
>> Robert, would you be able to give this latest version of the patch a
>> look?
>
> Yeah, sorry I've been completely side
2012/10/22 Tom Lane :
> Robert Haas writes:
>> On Mon, Oct 22, 2012 at 11:57 AM, Tom Lane wrote:
>>> Don't hold your breath. There are two ways the system could implement
>>> the DISTINCT clause: either sort and uniq, or hashaggregate.
>>> hashaggregate will destroy any input ordering, so there'
Robert Haas writes:
> Well, I think if that's the best we can do, you original proposal of
> ditching the column constraint syntax altogether might be for the
> best. I wasn't too excited about that before, but I think having two
> different syntaxes is going to be even worse. In some ways, it's
On Mon, Oct 22, 2012 at 2:29 PM, Tom Lane wrote:
> I'm not thrilled with the inconsistency either, but given the
> constraints we're under, it seems like the best we can do. (I feel,
> as Andrew does, that shoving WHERE into the table-constraint syntax
> would not be an improvement; but the colum
On 10/19/12 1:26 PM, Josh Berkus wrote:
What I'm saying is, we'll get nowhere promoting an application queue
which is permanently inferior to existing, popular open source software.
My advice: Forget about the application queue aspects of this. Focus
on making it work for replication and matvi
On Fri, Oct 12, 2012 at 10:47 PM, Stephen Frost wrote:
> * Marko Kreen (mark...@gmail.com) wrote:
>> As it works only on connect
>> time, it can actually be secure, unlike user switching
>> with SET ROLE.
>
> I'm guessing your issue with SET ROLE is that a RESET ROLE can be issued
> later..? If s
On Thu, Oct 18, 2012 at 7:42 PM, Claudio Freire wrote:
> Fun. That didn't take long.
>
> With the attached anti-sequential scan patch, and effective_io_concurrency=8:
>
>
> QUERY PLAN
> --
Kevin Grittner escribió:
> [I'm replying to Robert's message only because it is the latest on
> the thread; I'm actually kinda replying to the whole thread in
> general.]
Thanks for the great summary.
> (4) Subsequent discussion has produced a few shadowy hints at what
> such uses look like, with
Robert Haas writes:
> On Mon, Oct 22, 2012 at 11:57 AM, Tom Lane wrote:
>> Don't hold your breath. There are two ways the system could implement
>> the DISTINCT clause: either sort and uniq, or hashaggregate.
>> hashaggregate will destroy any input ordering, so there's no value in
>> using the i
[I'm replying to Robert's message only because it is the latest on
the thread; I'm actually kinda replying to the whole thread in
general.]
When catching up on a backlog, one would hope that any thread
comprising more than 5% of said backlog would be more constructive.
:-(
As someone coming in l
On Mon, Oct 22, 2012 at 12:08 PM, Tom Lane wrote:
> I wrote:
>> I tested, and indeed this seems to work:
>> CREATE TABLE t1 (c int[] WHERE EACH ELEMENT REFERENCES t2);
>> and it's perfectly sensible from an English-grammar standpoint too.
>> If we take that, how would we spell the table-cons
Robert Haas writes:
> On Mon, Oct 22, 2012 at 12:08 PM, Tom Lane wrote:
>> I wrote:
>>> I tested, and indeed this seems to work:
>>> CREATE TABLE t1 (c int[] WHERE EACH ELEMENT REFERENCES t2);
>>> and it's perfectly sensible from an English-grammar standpoint too.
>>> If we take that, how would w
On Mon, Oct 22, 2012 at 10:57 AM, Andrew Dunstan wrote:
> On 10/22/2012 10:18 AM, Robert Haas wrote:
>> On Sun, Oct 21, 2012 at 11:02 AM, Martijn van Oosterhout
>> wrote:
>>>
>>> It bugs me every time you have to jump through hoops and get red
>>> warnings for an unknown CA, whereas no encryption
On Mon, Oct 22, 2012 at 12:17 PM, Tom Lane wrote:
> Robert Haas writes:
>> The documentation lists several documented limitations that I would
>> like to analyze a little bit. First, it says that row-level security
>> policies are not applied on UPDATE or DELETE. That sounds downright
>> danger
On Mon, Oct 22, 2012 at 11:57 AM, Tom Lane wrote:
> Pavel Stehule writes:
>> but using DISTINCT breaks KNN searching optimization
>
>> postgres=# explain select distinct nazobce, nazobce <-> 'Benešov' from
>> obce order by nazobce <-> 'Benešov' limit 10
>
> Don't hold your breath. There are two
On 10/22/2012 12:53 PM, Sebastien FLAESCH wrote:
[Issues with unquoted utf8 identifiers in Windows 1252 locale]
I suspect this has something to do with the fact that non-quoted
identifiers
are converted to lowercase, and because my LC_CTYPE is English_United
States.1252,
the conversion to lowe
* Peter Eisentraut (pete...@gmx.net) wrote:
> On 10/12/12 3:44 PM, Stephen Frost wrote:
> > In general, I think it's good to build on existing implementations where
> > possible. Perhaps we could even consider using something which already
> > exists for this?
>
> Sounds like SASL to me.
aiui, t
Hi all,
I would appreciate some help or comments on this topic...
Is this the wrong mailing list to ask such question?
Seb
On 10/18/2012 10:15 AM, Sebastien FLAESCH wrote:
Hello,
Using PostgreSQL 9.2.1 on Windows, I am facing a strange character set
issue
with a UTF-8 database.
Maybe this is e
On 10/22/2012 12:13 PM, Andres Freund wrote:
On Monday, October 22, 2012 06:08:32 PM Tom Lane wrote:
I wrote:
I tested, and indeed this seems to work:
CREATE TABLE t1 (c int[] WHERE EACH ELEMENT REFERENCES t2);
and it's perfectly sensible from an English-grammar standpoint too.
If we
Robert Haas writes:
> The documentation lists several documented limitations that I would
> like to analyze a little bit. First, it says that row-level security
> policies are not applied on UPDATE or DELETE. That sounds downright
> dangerous to me. Is there some really compelling reason we're
On Monday, October 22, 2012 06:08:32 PM Tom Lane wrote:
> I wrote:
> > I tested, and indeed this seems to work:
> > CREATE TABLE t1 (c int[] WHERE EACH ELEMENT REFERENCES t2);
> >
> > and it's perfectly sensible from an English-grammar standpoint too.
> > If we take that, how would we spell th
On 10/22/2012 12:08 PM, Tom Lane wrote:
I wrote:
I tested, and indeed this seems to work:
CREATE TABLE t1 (c int[] WHERE EACH ELEMENT REFERENCES t2);
and it's perfectly sensible from an English-grammar standpoint too.
If we take that, how would we spell the table-constraint case exactly
2012/10/22 Tom Lane :
> I wrote:
>> I tested, and indeed this seems to work:
>> CREATE TABLE t1 (c int[] WHERE EACH ELEMENT REFERENCES t2);
>> and it's perfectly sensible from an English-grammar standpoint too.
>> If we take that, how would we spell the table-constraint case exactly?
>> Gramm
I wrote:
> I tested, and indeed this seems to work:
> CREATE TABLE t1 (c int[] WHERE EACH ELEMENT REFERENCES t2);
> and it's perfectly sensible from an English-grammar standpoint too.
> If we take that, how would we spell the table-constraint case exactly?
> Grammatically I'd prefer
> F
2012/10/22 Tom Lane :
> Pavel Stehule writes:
>> but using DISTINCT breaks KNN searching optimization
>
>> postgres=# explain select distinct nazobce, nazobce <-> 'Benešov' from
>> obce order by nazobce <-> 'Benešov' limit 10
>
> Don't hold your breath. There are two ways the system could impleme
Pavel Stehule writes:
> but using DISTINCT breaks KNN searching optimization
> postgres=# explain select distinct nazobce, nazobce <-> 'Benešov' from
> obce order by nazobce <-> 'Benešov' limit 10
Don't hold your breath. There are two ways the system could implement
the DISTINCT clause: eithe
On Sun, Oct 21, 2012 at 6:20 PM, Tom Lane wrote:
> Phil Sorber writes:
>> Here is the new patch. I renamed the utility from pg_ping to pingdb to
>> go along with the naming convention of src/bin/scripts.
>
> Uh, no, that's not a step forward. Leaving out a "pg" prefix from those
> script names i
On 10/12/12 3:44 PM, Stephen Frost wrote:
> wrt future-proofing, I don't like the "#-of-iterations" approach. There
> are a number of examples of how to deal with multiple encryption types
> being supported by a protocol, I'd expect hash'ing could be done in the
> same way. For example, Negotiate
On 10/22/2012 10:18 AM, Robert Haas wrote:
On Sun, Oct 21, 2012 at 11:02 AM, Martijn van Oosterhout
wrote:
It bugs me every time you have to jump through hoops and get red
warnings for an unknown CA, whereas no encryption whatsoever is treated
as fine while being actually even worse.
+1. Ame
Magnus, all,
* Magnus Hagander (mag...@hagander.net) wrote:
> On Thu, Oct 18, 2012 at 5:59 PM, Robert Haas wrote:
> > That seems like a sufficiently long deprecation window, but is gssapi
> > a full substitute for krb5? I don't really have a strong opinion on
> > this, not being a user myself.
>
On Sun, Oct 21, 2012 at 11:02 AM, Martijn van Oosterhout
wrote:
> It bugs me every time you have to jump through hoops and get red
> warnings for an unknown CA, whereas no encryption whatsoever is treated
> as fine while being actually even worse.
+1. Amen, brother.
--
Robert Haas
EnterpriseDB
Simon Riggs wrote:
> Greg Stark wrote:
>> Tom Lane wrote:
>>> Isn't there an even more serious problem, namely that this
>>> assumes *all* transactions are serializable?
Do you mean in terms of the serializable transaction isolation level,
or something else?
I haven't read the patches, but I've
On Mon, Oct 22, 2012 at 8:57 AM, Tom Lane wrote:
> Robert Haas writes:
>> The problems with MERGE are mostly around concurrency, as far as I can
>> tell. I can't see why RULEs would have anything to do with it -
>> except that I don't see how MERGE can sanely support rules, and even
>> if we fin
On Thu, Oct 18, 2012 at 2:19 PM, Alvaro Herrera
wrote:
> Kohei KaiGai escribió:
>> The revised patch fixes the problem that Daen pointed out.
>
> Robert, would you be able to give this latest version of the patch a
> look?
Yeah, sorry I've been completely sidelined this CommitFest. It's been
a cr
Hello
I should to search distinct values based on similarity
postgres=# explain select nazobce, nazobce <-> 'Benešov' from obce
order by nazobce <-> 'Benešov' limit 10
;
QUERY PLAN
---
Robert Haas writes:
> The problems with MERGE are mostly around concurrency, as far as I can
> tell. I can't see why RULEs would have anything to do with it -
> except that I don't see how MERGE can sanely support rules, and even
> if we find a way to make it do that, anyone already using RULEs w
On Fri, Oct 19, 2012 at 5:03 PM, Josh Berkus wrote:
>> That's a pretty neat one-liner. However... in my view, the real cost
>> of rules is that they are hard to support as we add new features to
>> SQL. I believe we already decided to punt on making them work with
>> CTEs... and maybe one other
Hi,
Now that the (at least as far as I know) last ordering problem in
pg_dump has been solved [1], I'm going to attempt resurrecting this old
thread.
It seemed to me that the biggest objections to this patch in the old
discussions were directed at the implementation, which I have tried to
i
On Saturday, October 20, 2012 11:07 PM Jeff Janes wrote:
> On Fri, Oct 19, 2012 at 11:00 PM, Amit kapila
> wrote:
> >
> >> Robert wrote an accounting patch a while ago that tallied how often a
> >> buffer was cleaned but then reclaimed for the same page before being
> >> evicted. But now I can't
48 matches
Mail list logo
