On 12/07/2011 02:34 AM, Shigeru Hanada wrote:
I think that only the owner of foreign table can keep collation
consistent between foreign and local, like data type of column. We need to
support per-column-collation on foreign tables too, or should deny pushing
down condition which is collation-se
As of commit fc6d1006bda783cc002c61a5f072905849dbde4b, the regression
tests leave an unused role sitting around, because that commit removed
DROP ROLE regress_test_role_super;
from foreign_data.sql. Was that intentional? If so, why?
regards, tom lane
--
Sent via
On 12/09/2011 06:48 PM, Ants Aasma wrote:
The attached test program (test_gettimeofday_monotonic) shows that one
test loop iteration takes 34ns with tsc and 1270ns with hpet.
This test program is great, I've wanted this exact sort of visibility
into this problem for years. I've toyed with
On Wed, Dec 7, 2011 at 9:40 AM, Greg Smith wrote:
> He estimated 22ns per gettimeofday on the system with fast timing
> calls--presumably using TSC, and possibly faster than I saw because his
> system had less cores than mine to worry about. He got 990 ns on his slower
> system, and a worst case
Andrew Dunstan wrote:
> >> Is there any good reason why we shouldn't build and install a dynamic
> >> libpgport.so?
> >
> > +1
> >
> > We've struggled with slony and pgport because so many users have had
> > problems with pgport not being included in some distributions. It has
> > some useful f
On Fri, Dec 09, 2011 at 03:43:19PM -0500, Robert Haas wrote:
> On Wed, Dec 7, 2011 at 8:42 AM, Noah Misch wrote:
> > It narrows the window for race conditions of that genesis, but isn't doing
> > so
> > an anti-feature? ?Even if not, doing that _only_ in RemoveRelations() is
> > odd.
>
> I dunn
Excerpts from Daniel Farina's message of Fri Dec 09 23:04:26 +0200 2011:
>
> I guess if I move the parenthetical grouping of logic around, what you
> are probably intending to say is "everyone except this one ecosystem
> does the normal thing, so we have an opportunity to Unite The Clans,
> by ab
On Fri, Dec 9, 2011 at 3:03 AM, Alexander Shulgin
wrote:
> The JDBC driver is special in that it intentionally does not use libpq.
> Given every other binding (think Ruby, Python, Perl, Tcl, etc.) does use
> libpq, it makes perfect sense to me to make the syntax compatible with JDBC.
I am wit
On 12/04/2011 12:44 PM, Andrew Dunstan wrote:
On 11/29/2011 04:32 PM, Brar Piening wrote:
Andrew Dunstan wrote:
Some minor nitpicks:
Do we really need to create all those VSProject.pm and
VSSolution.pm files? They are all always included anyway. Why
not just stash all the packag
On Wed, Dec 7, 2011 at 8:42 AM, Noah Misch wrote:
> It narrows the window for race conditions of that genesis, but isn't doing so
> an anti-feature? Even if not, doing that _only_ in RemoveRelations() is odd.
I dunno. I was just reluctant to change things without a clear reason
for doing so, an
On 12/09/2011 03:11 PM, Robert Haas wrote:
On Thu, Dec 8, 2011 at 12:46 PM, Andrew Dunstan wrote:
This is apparently an optimization bug in the compiler. If I turn
optimization off (CFLAGS=-O0) it goes away. Ick.
So at the moment I'm a bit blocked. I can't really file a bug because the
compi
On Thu, Dec 8, 2011 at 12:46 PM, Andrew Dunstan wrote:
> This is apparently an optimization bug in the compiler. If I turn
> optimization off (CFLAGS=-O0) it goes away. Ick.
>
> So at the moment I'm a bit blocked. I can't really file a bug because the
> compiler can't currently be used to build po
On Wed, Dec 7, 2011 at 1:40 PM, Marti Raudsepp wrote:
> Hi list,
>
> I found a 'pg_test_fsync.out' file in my $PGDATA, which was probably
> left around because I aborted pg_test_fsync with ^C back when setting
> up the server.
>
> Here's a patch to delete that file via a signal handler for
> SIGIN
Peter Eisentraut writes:
> The problem is, this breaks the regression tests, because first the
> actual output changes, and second the line numbers get included, which
> will create a mess every time you edit a test. Not sure whether we can
> work around that. Ideas?
Ugh, that's pretty nearly a
All,
This is currently awaiting a check by gsmith that the 7 named extensions
do not add any new dependancies.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.post
On lör, 2011-11-26 at 22:36 +0200, Peter Eisentraut wrote:
> There is a long-standing oddity in psql that running
>
> psql -f foo.sql
>
> returns error messages with file name and line number, like
>
> psql:foo.sql:1: ERROR: syntax error at or near "foo"
>
> but running
>
> psql < foo.sql doe
On 12/09/2011 01:01 PM, Steve Singer wrote:
On 11-12-09 11:13 AM, Andrew Dunstan wrote:
Recently I attempted to build an external package (pg_bulkload)
against the latest Fedora packages. Unfortunately this fails, as pgxs
adds "-lpgport" to any link line for an executable, and the
correspond
On 11-12-09 11:13 AM, Andrew Dunstan wrote:
Recently I attempted to build an external package (pg_bulkload)
against the latest Fedora packages. Unfortunately this fails, as pgxs
adds "-lpgport" to any link line for an executable, and the
corresponding libpgport.a isn't there. And in fact, pg_bu
Hello
2011/12/9 Albe Laurenz :
> Pavel Stehule wrote:
>> there is fixed version
>
> Here is my attempt at a doc patch.
>
> Could you add it to your patch so that all is in a single patch?
>
there is merged patch
Thank you
Regards
Pavel
> Yours,
> Laurenz Albe
check_function-2011-12-09-3.dif
On 9 December 2011 16:13, Andrew Dunstan wrote:
> Is there any good reason why we shouldn't build and install a dynamic
> libpgport.so?
+1 in favour of building and installing a dynamic libpgport.so. I
generally agree with your analysis.
I've seen this issue crop up a good few times now. I'm a F
Recently I attempted to build an external package (pg_bulkload) against
the latest Fedora packages. Unfortunately this fails, as pgxs adds
"-lpgport" to any link line for an executable, and the corresponding
libpgport.a isn't there. And in fact, pg_bulkload does use some of the
functionality th
Teodor Sigaev writes:
> [ spgist patch ]
I've been working through this patch and fixing assorted things.
There are a couple of issues that require some discussion:
1. It took me awhile to realize it, but there are actually three
different datatypes that can be stored in an SPGist index: the pre
Pavel Stehule wrote:
> there is fixed version
Here is my attempt at a doc patch.
Could you add it to your patch so that all is in a single patch?
Yours,
Laurenz Albe
check_function_docs.patch
Description: check_function_docs.patch
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgre
On Fri, Dec 9, 2011 at 6:03 AM, Alexander Shulgin
wrote:
> See above. The hope is that URIs will be compatible sans the driver-specific
> extra query parameters which might be not recognized by either party.
Yeah. I am not that concerned with being stupidity-compatible with
anyone else ... bu
On Thu, Dec 8, 2011 at 5:17 PM, Kohei KaiGai wrote:
> My first impression remind me an idea that I proposed before, even
> though it got negative response due to user visible changes.
> It requires superuser privilege to create new operators, since we
> assume superuser does not set up harmful con
On 03.12.2011 18:37, Heikki Linnakangas wrote:
One small change I'd like to make is to treat the loss of connection
more as a new "top-level" event, rather than as a new reason for query
cancellation. A lost connection is more like receiving SIGTERM, really.
Please take a look at the attached pat
Hi Hanada-san,
I updated the patch. Please find attached a patch.
Best regards,
Etsuro Fujita
> (2011/11/18 21:00), Shigeru Hanada wrote:
>> (2011/11/18 16:25), Etsuro Fujita wrote:
>>> Thank you for your testing. I updated the patch according to your
>>> comments. Attached is the updated ver
Pavel Stehule wrote:
> updated version
>
> changes:
>
> * CHECK FUNCTION ALL; is enabled - in this case functions from
> pg_catalog schema are ignored
>
> I looked on parser, and I didn't other changes there - IN SCHEMA, FOR
> ROLE are used more time there, so our usage will be consistent
> a smal
Excerpts from Daniel Farina's message of Mon Dec 05 11:56:19 +0200 2011:
>
> I think the current direction is fine, although as Robert Haas has
> said, I am not really at all inclined to view JDBC compatibility as
> any kind of a plus. JDBC URLs are weird, and do the drivers actually
> link libp
29 matches
Mail list logo
