On Fri, 2009-10-16 at 09:33 +0300, Heikki Linnakangas wrote:
> In advance-mode, we will merrilly skip over a WAL record that's a
> recovery stop target. Is that a bug or a feature?
Merrily?!? I saw it more as a sombre stepping motion.
Advance currently means set target at next record and continu
On Sun, 2009-09-20 at 17:54 -0400, Tom Lane wrote:
> (I'm wondering a bit if anyone will want a WHERE clause, too, though
> adding that later shouldn't pose any big syntactic obstacles.)
Where should I put the WHERE clause? My current syntax (with patch) is:
[ CONSTRAINT constraint_name ]
EXCLU
On Thu, 2009-10-15 at 19:58 -0400, Tom Lane wrote:
> Alvaro Herrera writes:
> > Hmm ... this is something that had not occured to me earlier. There is
> > a connection pool here (JDBCConnectionPool I'm told; hadn't heard about
> > that one) and there are about 100 backends permanently, not all of
On Thu, 2009-10-15 at 16:54 -0500, Kevin Grittner wrote:
> Dimitri Fontaine wrote:
>
> > It's pretty often the case (IME) that calling a trigger is the only
> > point in the session where you fire plpgsql, and that's a visible
> > cost.
>
> Wouldn't a connection pool solve this?
No
--
Simo
On Fri, 2009-10-16 at 10:14 +0900, Itagaki Takahiro wrote:
> Tom Lane wrote:
>
> > Itagaki Takahiro writes:
> > > I think there is a benefit to provide WHEN cluase at least
> > > for compatibility with other DBMSs, even through we can move
> > > the expressions into the body of trigger functions
KaiGai Kohei wrote:
> The purpose of this patch is to provide function entrypoints for the
> upcoming SE-PostgreSQL feature, because I got a few comments that we
> hesitate to put sepgsql_xxx() hooks on the main routines directly in
> the first commit fest. In addition, I already tried to put SE-PG
(HTML mail to preserve formatting; let's see if it works.)
I like the new Unicode tables, but the marking of continuation lines
looks pretty horrible:
List of databases
Name │ Owner │ Encoding │ Collation │ Ctype │ Access
privileges
───┼───┼─
On Thu, Oct 15, 2009 at 11:44 PM, Greg Sabino Mullane wrote:
> The DELETE returns 0 rows (and thus is the problem) according to the script.
I've had this problem before when there is a BEFORE DELETE trigger
that is inadvertently preventing the deletion, though this seems hard
to rationalize with
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> The DELETE returns 0 rows (and thus is the problem) according to the script.
> I've had this problem before when there is a BEFORE DELETE trigger
> that is inadvertently preventing the deletion, though this seems hard
> to rationalize with the
On Fri, 2009-10-16 at 09:31 +0100, Simon Riggs wrote:
> * It will reduce size of in-memory pending trigger list (for large
> statements)
But this won't be the outcome when it's implemented the way it is being
proposed, which checks the where clause just before executing the
trigger function.
--
On Fri, Oct 16, 2009 at 01:38:15PM +0300, Peter Eisentraut wrote:
> (HTML mail to preserve formatting; let's see if it works.)
>
> I like the new Unicode tables, but the marking of continuation lines
> looks pretty horrible:
Yes, I'm not so keen myself. The ASCII characters used are '|', ':' and
I believe the attached patch is ready for review at the next
commitfest. It does the following:
- Adds a userset GUC called application_name.
- Allows application_name to be reported in log_line_prefix using %a.
- Includes application_name in CSV logs.
- Displays application_name in the output of
On Fri, 2009-10-16 at 14:39 +0300, Peter Eisentraut wrote:
> On Fri, 2009-10-16 at 09:31 +0100, Simon Riggs wrote:
> > * It will reduce size of in-memory pending trigger list (for large
> > statements)
>
> But this won't be the outcome when it's implemented the way it is being
> proposed, which ch
Peter Eisentraut writes:
> On Fri, 2009-10-16 at 09:31 +0100, Simon Riggs wrote:
>> * It will reduce size of in-memory pending trigger list (for large
>> statements)
> But this won't be the outcome when it's implemented the way it is being
> proposed, which checks the where clause just before exe
On Fri, 2009-10-16 at 10:02 -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > On Fri, 2009-10-16 at 09:31 +0100, Simon Riggs wrote:
> >> * It will reduce size of in-memory pending trigger list (for large
> >> statements)
>
> > But this won't be the outcome when it's implemented the way it is
Simon Riggs writes:
> If the function is idempotent then we can also optimise away multiple
> calls by checking whether a similar call is already queued.
But how would we know that? It seems orthogonal to this patch,
anyway.
regards, tom lane
--
Sent via pgsql-hackers
Jeff Davis writes:
> I tried to move the WHERE clause right before or after the
> index_parameters, but that resulted in shift/reduce conflicts.
You could avoid the conflicts in at least two ways:
* require parens around the WHERE expression
* stick the WHERE inside the EXCLUSION ( ... ) bit, s
On Fri, 16 Oct 2009, Tom Lane wrote:
> I note BTW that we have some ad-hoc logic already that arranges to
> suppress queuing of AFTER events for FK triggers, if the FK column
> value has not changed. It might be interesting to look at whether
> that hack could be unified with the user-accessible
Stephan Szabo writes:
> On Fri, 16 Oct 2009, Tom Lane wrote:
>> I note BTW that we have some ad-hoc logic already that arranges to
>> suppress queuing of AFTER events for FK triggers, if the FK column
>> value has not changed. It might be interesting to look at whether
>> that hack could be unifi
Robert Haas wrote:
> > Sure, the logfile will be filled with mixed encoding strings,
> > that could happen in logfile and syslog on non-win32 platforms.
> > I think UTF8 is better than UTF16 for logfile encoding because
> > there are some text editors that do not support wide characters.
> > At any
Tom Lane wrote:
> Robert Haas writes:
> > If we were using some kind of real public key system and someone
> > suggested breaking it to add password complexity checking, I would
> > understand the outrage here. But I don't understand why everyone is
> > so worked up about having an *optional* *fl
Dave Page wrote:
> Too many of those caveats, and it's easy to see how we can be
> discounted early in the evaluation phase. It's not helped that often
> these lists will be drawn up by people used to working with the
> commercial DBMSs, so we probably wouldn't get extra points for having
> a dozen
Bruce Momjian writes:
> So, are we agreed to provide a hook on the server side, but to use it
> you have to configure your system with SSL and 'password'? I can add
> that to the TODO list.
I think we're agreed to provide the hook. What restrictions the hook
might enforce are not our concern.
On 10/16/2009 11:28 AM, Bruce Momjian wrote:
Dave Page wrote:
Too many of those caveats, and it's easy to see how we can be
discounted early in the evaluation phase. It's not helped that often
these lists will be drawn up by people used to working with the
commercial DBMSs, so we probably wo
2009/10/16 KaiGai Kohei :
> . In addition, I already tried to put SE-PG hooks
> within pg_xxx_aclchecks() in this CF, but it was failed due to the
> differences in the security models.
I thought the last discussion ended with a pretty strong conclusion
that we didn't want differences in the securi
Folks,
We have some really silly legacy stuff in PostgreSQL, the silliest of
which, as far as I've found, is the add_missing_from GUC.
Since it's been deprecated, as in off by default, since 8.1, I'd like
to suggest that we remove it from both docs and code and throw an
error if someone tries to
On Fri, Oct 16, 2009 at 4:28 PM, Bruce Momjian wrote:
> Personally I think the calculator/wires approach is better from an
> engineering perspective, but it can be a handicap in the user experience
> and checkbox categories --- ease of use is perhaps not our strong point.
> Much of our open source
David Fetter writes:
> We have some really silly legacy stuff in PostgreSQL, the silliest of
> which, as far as I've found, is the add_missing_from GUC.
Considering that we just had a discussion about a significant
application that's still using it, I'm not sure what's your hurry.
Is your intent
Greg Stark writes:
> The first step is to add hooks which don't change the security model
> at all, just allow people to control the existing checks from their SE
> configuration.
This is in fact what the presented patch is meant to do. The issue is
about whether the hook placement is sane/usefu
Tom Lane wrote:
> Bruce Momjian writes:
> > So, are we agreed to provide a hook on the server side, but to use it
> > you have to configure your system with SSL and 'password'? I can add
> > that to the TODO list.
>
> I think we're agreed to provide the hook. What restrictions the hook
> might
Mark Mielke wrote:
> > Personally I think the calculator/wires approach is better from an
> > engineering perspective, but it can be a handicap in the user experience
> > and checkbox categories --- ease of use is perhaps not our strong point.
> > Much of our open source value is being different, i
On Fri, Oct 16, 2009 at 12:45 PM, Greg Stark wrote:
> 2009/10/16 KaiGai Kohei :
>> . In addition, I already tried to put SE-PG hooks
>> within pg_xxx_aclchecks() in this CF, but it was failed due to the
>> differences in the security models.
>
> I thought the last discussion ended with a pretty st
On Fri, Oct 16, 2009 at 01:23:16PM -0400, Tom Lane wrote:
> David Fetter writes:
> > We have some really silly legacy stuff in PostgreSQL, the silliest
> > of which, as far as I've found, is the add_missing_from GUC.
>
> Considering that we just had a discussion about a significant
> application
On Fri, Oct 16, 2009 at 10:23 AM, Tom Lane wrote:
> (I would actually not mind getting rid of it, because that would greatly
> simplify a problem I'm wrestling with right now, namely how to put hooks
> into the parser for resolution of plpgsql variables. But we need to be
> honest about what it's
On Thu, 2009-10-15 at 00:43 +0300, Peter Eisentraut wrote:
> On Sun, 2009-10-04 at 10:48 -0400, Tom Lane wrote:
> > Peter Eisentraut writes:
> > > I understand the annoyance, but I think we do need to have an organized
> > > way to do testing of non-ASCII data and in particular UTF8 data, because
Peter Eisentraut writes:
> Actually, what I committed was really the output I got. Now with your
> commit my tests started failing again.
Huh --- what I committed is what I got on a Fedora 11 machine. Maybe
we need both variants?
> Let's see what the Solaris builds say now.
We'll know for sur
On Fri, 2009-10-16 at 15:14 -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > Actually, what I committed was really the output I got. Now with your
> > commit my tests started failing again.
>
> Huh --- what I committed is what I got on a Fedora 11 machine. Maybe
> we need both variants?
I
Greg Stark writes:
> On Fri, Oct 16, 2009 at 10:23 AM, Tom Lane wrote:
>> (I would actually not mind getting rid of it, because that would greatly
>> simplify a problem I'm wrestling with right now, namely how to put hooks
>> into the parser for resolution of plpgsql variables. But we need to be
Peter Eisentraut writes:
> On Fri, 2009-10-16 at 15:14 -0400, Tom Lane wrote:
>> Huh --- what I committed is what I got on a Fedora 11 machine. Maybe
>> we need both variants?
> It depends on what LC_CTYPE is set to on the client side.
I was testing the same case as the problematic Solaris test
On Fri, Oct 16, 2009 at 9:26 PM, Tom Lane wrote:
> So, while I do think it's something we should leave alone until it gets
> in the way, this is a sufficiently large value of "in the way" that I'm
> willing to talk about removing add_missing_from. I'm just concerned
> about the impact of that, co
On Oct 6, 2009, at 2:57 PM, Oleg Bartunov wrote:
this is an announcement of our new contribution module for
PostgreSQL - Plantuner - enable planner hints
(http://www.sai.msu.su/~megera/wiki/plantuner).
=# set enable_seqscan=off;
=# set plantuner.forbid_index='id_idx2';
Out of curiosity, did
On Oct 16, 2009, at 10:04 AM, decibel wrote:
Out of curiosity, did you look at doing hints as comments in a query?
I don't think that a contrib module could change the grammar.
--
-- Christophe Pettus
x...@thebuild.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
On Fri, 2009-10-16 at 12:04 -0500, decibel wrote:
> I'm guessing you couldn't actually do that in just a contrib module,
> but it's how Oracle handles hints, and it seems to be *much* more
> convenient, because a hint only applies for a specific query.
If that's the only reason, that seems eas
2009/10/13 Itagaki Takahiro :
>
> Magnus Hagander wrote:
>
>> One other question - you note that WriteConsoleW() "could fail if
>> stderr is redirected". Are you saying that it will always fail when
>> stderr is redirected, or only sometimes? If ony sometimes, do you know
>> under which conditions
On Fri, Oct 16, 2009 at 12:26 PM, Tom Lane wrote:
> However, if the columnref looks like "x.y" where x happens to
> match some table in the database (and not in the query) that doesn't
> have a column y, the implicit-RTE code will have already modified the
> querytree before finding out that colum
On Fri, Oct 16, 2009 at 10:04 AM, decibel wrote:
> Out of curiosity, did you look at doing hints as comments in a query? I'm
> guessing you couldn't actually do that in just a contrib module, but it's
> how Oracle handles hints, and it seems to be *much* more convenient, because
> a hint only appl
Heikki Linnakangas wrote:
> KaiGai Kohei wrote:
>> The purpose of this patch is to provide function entrypoints for the
>> upcoming SE-PostgreSQL feature, because I got a few comments that we
>> hesitate to put sepgsql_xxx() hooks on the main routines directly in
>> the first commit fest. In additi
Greg Stark wrote:
2009/10/16 KaiGai Kohei :
. In addition, I already tried to put SE-PG hooks
within pg_xxx_aclchecks() in this CF, but it was failed due to the
differences in the security models.
I thought the last discussion ended with a pretty strong conclusion
that we didn't want differenc
On Fri, 16 Oct 2009, Greg Stark wrote:
It only affects OpenACS if they want to upgrade to 8.5 which will
presumably mean other application changes as well. Though probaby none
requiring as much major code changes as this.
Being one that hosts alot of OACS sites, and has a fair experience with
On Fri, 16 Oct 2009, Tom Lane wrote:
So, while I do think it's something we should leave alone until it gets
in the way, this is a sufficiently large value of "in the way" that I'm
willing to talk about removing add_missing_from. I'm just concerned
about the impact of that, considering that a
50 matches
Mail list logo
