On ons, 2011-11-30 at 17:56 -0500, Robert Haas wrote:
On Wed, Nov 30, 2011 at 3:58 PM, Stephen Frost sfr...@snowman.net wrote:
Erm, isn't there a contrib type that already does all that for you..?
ip4r or whatever? Just saying, if you're looking for that capability..
Oh, huh, good to
On 04.10.2011 09:43, Fujii Masao wrote:
On Mon, Oct 3, 2011 at 4:32 PM, Simon Riggssi...@2ndquadrant.com wrote:
I don't think this should use the rm_safe_restartpoint machinery. As you
said, it's not tied to any specific resource manager. And I've actually been
thinking that we will get rid of
On ons, 2011-11-30 at 10:53 -0500, Tom Lane wrote:
I think the important point here is that we need to support more than
one level of validation, and that the higher levels can't really be
applied by default in CREATE FUNCTION because they may fail on perfectly
valid code.
How would this work
Tom Lane wrote:
Do I understand right that the reason why the check function is
different from the validator function is that it would be more
difficult
to add the checks to the validator function?
Is that a good enough argument? From a user's perspective it is
difficult to see why some
Rebased with head.
--
With best regards,
Alexander Korotkov.
rangetypegist-0.4.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
I tried to implement remaining portion of the object creation permission patches
using this approach; that temporary saves contextual information using existing
ProcessUtility hook and ExecutorStart hook.
It likely works fine towards my first problem; system catalog entry
does not have
all the
On 17.11.2011 17:24, Tom Lane wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com writes:
When the FDW recognizes it's being asked to join a ForeignJoinPath and a
ForeignPath, or two ForeignJoinPaths, it throws away the old SQL it
constructed to do the two-way join, and builds a new
On 2 December 2011 01:13, Tom Lane t...@sss.pgh.pa.us wrote:
Regardless of that, I'm still of the opinion that this patch is
fundamentally misdesigned. The way it's set up, it is only possible to
have a fast path for types that are hard-wired into tuplesort.c, and
that flies in the face of
* Peter Eisentraut (pete...@gmx.net) wrote:
- ip4 really only stores a single address, not a netmask, not sometimes
a netmask, or sometimes a range, or sometimes a network and an address,
or whatever. That really seems like the most common use case, and no
matter what you do with the other
On Fri, Dec 2, 2011 at 3:42 AM, Peter Eisentraut pete...@gmx.net wrote:
- ip4 is fixed-length, so it's much faster. (Obviously, this is living
on borrowed time. Who knows.)
Fair point.
- Conversely, it might be considered a feature that ip4 only stores IPv4
addresses.
True, although this
On Fri, Dec 2, 2011 at 12:16 AM, Tom Lane t...@sss.pgh.pa.us wrote:
It should be the same or better. Right now, we are going through
FunctionCall2Coll to reach the FCI-style comparator. The shim function
would be more or less equivalent to that, and since it's quite special
purpose I would
- Цитат от Tom Lane (t...@sss.pgh.pa.us), на 02.12.2011 в 05:21 -
Robert Haas robertmh...@gmail.com writes:
On Thu, Dec 1, 2011 at 7:56 PM, Stephen Frost sfr...@snowman.net wrote:
I don't have any particular care about if cidr has indexing support or
not. I'm certainly not *against*
Peter Eisentraut pete...@gmx.net writes:
On ons, 2011-11-30 at 10:53 -0500, Tom Lane wrote:
I think the important point here is that we need to support more than
one level of validation, and that the higher levels can't really be
applied by default in CREATE FUNCTION because they may fail on
Robert Haas robertmh...@gmail.com writes:
OK, but I think it's also going to cost you an extra syscache lookup,
no? You're going to have to check for this new support function
first, and then if you don't find it, you'll have to check for the
original one. I don't think there's any
In Postgres 8.4, pg_upgrade preserved pg_class relfilenodes by creating
files in the file system. In Postgres 9.0, we changed this by creating
pg_upgrade_support functions which allow us to directly preserve
pg_class.oids.
Unfortunately, check.c was not updated to reflect this and clusters
2011/12/1 Kris Jurka bo...@ejurka.com
On Wed, 30 Nov 2011, Joel Jacobson wrote:
As you know, LISTEN/NOTIFY is broken in the Java client library. You
have to
do a SELECT 1 in a while-loop to receive the notifications.
http://jdbc.postgresql.org/documentation/head/listennotify.html
On 2011-12-01 22:14, Peter Eisentraut wrote:
On tor, 2011-12-01 at 14:37 +0100, Yeb Havinga wrote:
On 2011-11-29 18:47, Peter Eisentraut wrote:
On tis, 2011-11-29 at 07:07 +0200, Peter Eisentraut wrote:
On mån, 2011-11-28 at 11:41 +0100, Yeb Havinga wrote:
On 2011-11-15 21:50, Peter
On Thu, Dec 1, 2011 at 6:21 AM, Joel Jacobson j...@trustly.com wrote:
2011/12/1 Kris Jurka bo...@ejurka.com
On Wed, 30 Nov 2011, Joel Jacobson wrote:
As you know, LISTEN/NOTIFY is broken in the Java client library. You
have to
do a SELECT 1 in a while-loop to receive the notifications.
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Tom, what do you think of this part? I think it would be a lot more
natural API if the planner could directly ask the FDW to construct a
plan for a three (or more)-way join, instead of asking it to join a join
relation into
Hello
Also, what kind of report does this generate?
Good question. I suspect what Pavel has now will raise errors, but that
doesn't scale very nicely to checking more than one function, or even to
finding more than one bug in a single function.
I stop on first error now. Reason is reuse
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
OK, but I think it's also going to cost you an extra syscache lookup,
no? You're going to have to check for this new support function
first, and then if you don't find it, you'll have to check for the
original one. I don't think
[ shrug... ] If you are bothered by that, get off your duff and provide
the function for your datatype. But it's certainly going to be in the
noise for btree index usage, and I submit that query parsing/setup
involves quite a lot of syscache lookups already. I think that as a
performance
On Fri, Dec 2, 2011 at 2:35 PM, Bruce Momjian br...@momjian.us wrote:
Agreed. Doing something once and doing something in the sort loop are
two different overheads.
OK, so I tried to code this up. Adding the new amproc wasn't too
difficult (see attached). It wasn't obvious to me how to tie
Hello
My attempt at a syntax that could also cover Peter's wish for multiple
checker functions:
CHECK FUNCTION { func(args) | ALL [IN SCHEMA schema] [FOR ROLE user] }
[ USING check_function ] OPTIONS (optname optarg [, ...])
check_function should be related to one language, so you have
Robert Haas wrote:
On Fri, Dec 2, 2011 at 2:35 PM, Bruce Momjian br...@momjian.us wrote:
Agreed. ?Doing something once and doing something in the sort loop are
two different overheads.
OK, so I tried to code this up. Adding the new amproc wasn't too
difficult (see attached). It wasn't
2011/12/2 Pavel Stehule pavel.steh...@gmail.com:
Hello
My attempt at a syntax that could also cover Peter's wish for multiple
checker functions:
CHECK FUNCTION { func(args) | ALL [IN SCHEMA schema] [FOR ROLE user] }
[ USING check_function ] OPTIONS (optname optarg [, ...])
some other
All:
*ping*
Trying to restart this discussion, since the feature bogged down on
spec. We have consensus that we need to change how replication mode is
mangaged; surely we can reach consensus on how to change it?
On 11/8/11 11:39 AM, Josh Berkus wrote:
configuration data somewhere else, but
On 02.12.2011 18:55, Tom Lane wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com writes:
Tom, what do you think of this part? I think it would be a lot more
natural API if the planner could directly ask the FDW to construct a
plan for a three (or more)-way join, instead of asking it
Hi,
Hm. I just noticed a relatively big hole in the patch: The handling of
deletion of dependent objects currently is nonexistant because they don't go
through ProcessUtility...
Currently thinking what the best way to nicely implement that is. For other
commands the original command string is
Kevin Grittner kevin.gritt...@wicourts.gov wrote:
Robert Haas robertmh...@gmail.com wrote:
Kevin Grittner kevin.gritt...@wicourts.gov wrote:
The extraWaits code still looks like black magic to me
[explanation of the extraWaits behavior]
Thanks. I'll spend some time reviewing this part.
On 24.11.2011 23:56, Jan Urbański wrote:
On 24/11/11 16:15, Heikki Linnakangas wrote:
On 24.11.2011 10:07, Jan Urbański wrote:
On 23/11/11 17:24, Mika Eloranta wrote:
[PL/Python in 9.1 does not preserve SQLSTATE of errors]
Oops, you're right, it's a regression from 9.0 behaviour.
The fix
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
I have applied the attached patch to mention the debugger. OK?
Server developers should consider using the configure options
option--enable-cassert/ and option--enable-debug/ to
enhance the
ability to
Hi all,
There is also the point about how permission checks on the actual commands (in
comparison of modifying command triggers) and such are handled:
BEFORE and INSTEAD will currently be called independently of the fact whether
the user is actually allowed to do said action (which is
Heikki tipped me off to a possible problem with CLOG contention that
he noticed while doing some benchmarking, and so I (you know what's
coming, right?) tried to reproduce it on Nate Boley's 32-core AMD
machine. It turns out that increasing NUM_CLOG_BUFFERS from 8 to 32
delivers a significant
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
On 02.12.2011 18:55, Tom Lane wrote:
Furthermore, you seem to be imagining that there is only one best path
for any join, which isn't the case.
No, I understand that the planner considers many alternatives, even at
the same
On 03.12.2011 00:24, Tom Lane wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com writes:
On 02.12.2011 18:55, Tom Lane wrote:
Furthermore, you seem to be imagining that there is only one best path
for any join, which isn't the case.
No, I understand that the planner considers
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Hmm, so you're saying that the FDW function needs to be able to return
multiple paths for a single joinrel. Fair enough, and that's not
specific to remote joins. Even a single-table foreign scan could be
implemented differently
Hi,
First thing first: thank you Andres for a great review, I do appreciate
it. Please find attached a newer version of the patch. The github
repository is also updated.
Andres Freund and...@anarazel.de writes:
I think at least a
* command_tagtext
Added.
Why is there explicit
On Thu, Dec 1, 2011 at 3:47 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Nov 29, 2011 at 9:10 PM, Daniel Farina dan...@heroku.com wrote:
Reviving a thread that has hit its second birthday:
http://archives.postgresql.org/pgsql-hackers/2009-11/msg00024.php
In our case not being able to
On Fri, Dec 2, 2011 at 6:25 PM, Daniel Farina dan...@heroku.com wrote:
Here's a protocol: have pg_start_backup() write a file that just means
backing up. Restarts are OK, because that's all it means, it has no
meaning to a recovery/restoration process.
When one wishes to restore, one must
Excerpts from Andres Freund's message of vie dic 02 19:09:47 -0300 2011:
Hi all,
There is also the point about how permission checks on the actual commands
(in
comparison of modifying command triggers) and such are handled:
BEFORE and INSTEAD will currently be called independently of
On Fri, Dec 2, 2011 at 7:09 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Hmm, we currently even have a patch (or is it already committed?) to
avoid locking objects before we know the user has permission on the
object. Getting to the point of calling the trigger would surely be
even
On Saturday, December 03, 2011 01:09:48 AM Alvaro Herrera wrote:
Excerpts from Andres Freund's message of vie dic 02 19:09:47 -0300 2011:
Hi all,
There is also the point about how permission checks on the actual
commands (in comparison of modifying command triggers) and such are
On Fri, Dec 2, 2011 at 6:52 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
At least, it is working. However, it is not a perfect solution to the
future updates
of code paths in the core.
Hmm. So, do you want this committed? If so, I think the major thing
it lacks is documentation.
I can't help
44 matches
Mail list logo
