On Dec 30, 2009, at 9:50 PM, Bruce Momjian wrote:
> 3) There is no easy way to analyze all databases. vacuumdb --analyze
> does analyze _and_ vacuum, which for an 8.4 to 8.5 migration does an
> unnecessary vacuum. Right now I recommend ANALYZE in every database,
> but it would be nice if there w
On Dec 29, 2009, at 6:29 PM, Tom Lane wrote:
> * when a tabstat message comes in, increment changes_since_analyze by
> the sum of t_tuples_inserted + t_tuples_updated + t_tuples_deleted;
>
> * when an analyze report message comes in, reset changes_since_analyze
> to zero.
If that's being added, c
On Wed, Jan 6, 2010 at 1:12 AM, Takahiro Itagaki
wrote:
>
> What reason do we have not to inherit typmodin/typmodout from the base type?
> I found a comment in DefineDomain(),
> /* Domains never accept typmods, so no typmodin/typmodout needed */
> but can we relax the restriction? This feature
Hi,
I'm trying to use DOMAIN as just synonym types for database migration.
For example,
=# CREATE DOMAIN varchar2 AS pg_catalog.varchar;
=# CREATE DOMAIN number AS pg_catalog.numeric;
Domains were created successfully, but I cannot use type modifiers for them.
=# CREATE TABLE tbl (v v
Simon Riggs wrote:
> > 1. Commit your patch, as-is (you/me)
>
> I assume this is OK with you now?
I just applied the patch with a few additional comments.
Also, I adjusted some messages for vacuumdb to be look-alike
for recently-committed --only-analyze patch.
Remaining ToDo items are:
>> 2.
On Sat, Dec 26, 2009 at 10:55 AM, Fujii Masao wrote:
> On Fri, Dec 25, 2009 at 9:56 PM, Andrew Dunstan wrote:
>> I don't see the use case for it - .pgpass is for single users, not a whole
>> cluster. And it does support wildcards, which takes care of the 'all' case.
>> In the case of pg_hba.conf
Robert Haas wrote:
Getting full?
...Robert
Ok. Bad analogy. We have the tables setup to write data according to
the month it was loaded. We have a December table, a January table and
so on. Basically following the examples given on the 8.4 web site.
I'm thinking it would be nice if
Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > > 3) There is no easy way to analyze all databases. vacuumdb --analyze
> > > does analyze _and_ vacuum, which for an 8.4 to 8.5 migration does an
> > > unnecessary vacuum. Right now I recommend ANALYZE in every database,
> > > but it would be nice
Bruce Momjian wrote:
> Bruce Momjian wrote:
> > pg_migrator has become more popular recently, so it seems time to look
> > at some enhancements that would improve pg_migrator. None of these are
> > required, but rather changes that would be nice to have:
> >
> > 1) Right now pg_migrator preserve
Bruce Momjian wrote:
> I am seeing a compile failure in current CVS because my operating
> system, BSD/OS, does not have inttypes.h:
>
> ccache gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith
> -fno-strict-aliasing -O1 -Wall -Wmissing-prototypes
> -Wmissing-declarations -Wpoin
On Tue, Jan 5, 2010 at 6:09 PM, Arie Bikker wrote:
> Hi all,
>
> Well I had to burn some midnight oil trying to figure out why a construct
> like
> SELECT xpath('name()','');
> doesn't give the expected result. Kept getting an empty array:
> xpath
> -
> {}
> instead of the expected "
I am seeing a compile failure in current CVS because my operating
system, BSD/OS, does not have inttypes.h:
ccache gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith
-fno-strict-aliasing -O1 -Wall -Wmissing-prototypes
-Wmissing-declarations -Wpointer-arith -Wcast-align -pth
On Tue, Jan 5, 2010 at 12:22 AM, Heikki Linnakangas
wrote:
> I've merged the replication branch with PostgreSQL CVS HEAD now,
> including the patch for end-of-backup WAL records I committed earlier
> today. See 'replication' branch in my git repository.
>
> There's also a couple of other small cha
On Tue, Jan 5, 2010 at 11:29 PM, Alvaro Herrera
wrote:
> This was probably discussed to death earlier, but: why was it decided to
> not simply use a different port for listening for walsender
> connections?
I believe that using a different port would make the setup
of replication messier; look fo
On Tue, Jan 5, 2010 at 11:07 PM, Heikki Linnakangas
wrote:
> I think it would be better to utilize the existing array of child
> processes in pmsignal.c. Instead of having postmaster peek into
> WalSndCtlData, let's add a new state to PMChildFlags,
> PM_CHILD_WALSENDER, which is just like PM_CHILD
On Tue, Jan 5, 2010 at 8:00 PM, u235sentinel wrote:
> http://www.postgresql.org/docs/8.4/static/ddl-partitioning.html
>
> Is there a way to automatically extend table partitions? I'm curious if /
> when a table is getting full if there is a way for postgres to create
> additional tables.
Getting
http://www.postgresql.org/docs/8.4/static/ddl-partitioning.html
Is there a way to automatically extend table partitions? I'm curious if
/ when a table is getting full if there is a way for postgres to create
additional tables. Or is it all manual?
Thanks :D
--
Sent via pgsql-hackers mail
Arie Bikker wrote:
Hi all,
Well I had to burn some midnight oil trying to figure out why a
construct like
SELECT xpath('name()','');
doesn't give the expected result. Kept getting an empty array:
xpath
-
{}
instead of the expected "{a}"
BugID 4294 and the TODO item "better handl
Tim Bunce writes:
> The only question I have at the moment, before I try implementing this,
> is the the need for freeing the plan. When would that be needed?
There's probably no strong need to do it at all, unless you are dropping
your last reference to the plan.
regards
Tim Bunce writes:
> On Thu, Dec 31, 2009 at 09:47:24AM -0800, David E. Wheeler wrote:
>> Definite benefit, there. How does it handle the difference between
>> IMMUTABLE | STABLE | VOLATILE, as well as STRICT functions?
> It doesn't at the moment. I think IMMUTABLE, STABLE and VOLATILE can be
> (d
Hi all,
Well I had to burn some midnight oil trying to figure out why a
construct like
SELECT xpath('name()','');
doesn't give the expected result. Kept getting an empty array:
xpath
-
{}
instead of the expected "{a}"
BugID 4294 and the TODO item "better handling of XPath data ty
Ok, Plan B...
Consider this (hypothetical) example:
CREATE OR REPLACE FUNCTION test() ... LANGUAGE plperl AS $$
use SP foo_int => 'foo(int)';
use SP foo_text => 'foo(text)', -cached;
foo_int(42);
foo_text(42);
...
$$
Here the user is importing i
On Tue, 2010-01-05 at 03:09 -0500, Tom Lane wrote:
> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jaguar&dt=2010-01-05%2004:00:03
> (and the same a couple times before this...)
>
> Core was generated by `postgres: autovacuum worker process regression
>'.
> I agree with Tom's statement upthread that we should only count the
> rows affected by the top-level query. Anything else seems extremely
> counter-intuitive.
I'm ok with that. I don't think there is any kind of intuitive behavior
in this situation, and we just need to pick something and docu
On Tue, Jan 5, 2010 at 4:20 PM, Josh Berkus wrote:
> On 1/5/10 9:45 AM, Marko Tiikkaja wrote:
>> On 2010-01-05 19:21 +0200, Greg Stark wrote:
>>> with t as (delete from foo returning *)
>>> select * from t where x=?
>>>
>>> applications will almost certainly expect the number to match the
>>> actu
On Tue, Dec 29, 2009 at 9:12 PM, Tom Lane wrote:
> Robert Haas writes:
>> Yep. It would also lower the barrier to future innovations of that
>> type, which would be a good thing, IMO. Unfortunately we'd likely
>> need to continue to support the existing syntax at least for
>> attstattarget, whi
On Tue, Jan 05, 2010 at 01:05:40PM -0800, David E. Wheeler wrote:
> On Jan 5, 2010, at 12:59 PM, Tim Bunce wrote:
>
> > So you're suggesting SP::foo(...) _always_ executes foo(...) via bunch
> > of spi_* calls. Umm. I thought performance was a major driving factor.
> > Sounds like you're more keen
Jeff Davis wrote:
> Is a full table lock acceptable in the end? If so, then predicate
> locking is just optimization, and we should leave it until later.
I think that the predicate locking will need to be RAM-based to
provide acceptable performance, and that we will need a
multi-granularity ap
On 1/5/10 9:45 AM, Marko Tiikkaja wrote:
> On 2010-01-05 19:21 +0200, Greg Stark wrote:
>> with t as (delete from foo returning *)
>> select * from t where x=?
>>
>> applications will almost certainly expect the number to match the
>> actual number of rows returned and may well misbehave if they do
On tis, 2010-01-05 at 11:50 -0800, Scott Bailey wrote:
> > There has been talk about adding something like xpath_string,
> > xpath_number, xpath_boolean for fetching xpath expressions that
> don't
> > return nodesets. I think that would fit your use case.
>
> The first two sound very much like wh
On Tue, 2010-01-05 at 13:47 -0600, Kevin Grittner wrote:
> I will not
> spend any significant amount of time looking at the specifics of any
> particular optimizations yet, because such premature optimization is
> certain to kill the whole project.
I'm certainly not trying to derail the project, I
On Jan 5, 2010, at 12:59 PM, Tim Bunce wrote:
> So you're suggesting SP::foo(...) _always_ executes foo(...) via bunch
> of spi_* calls. Umm. I thought performance was a major driving factor.
> Sounds like you're more keen on syntactic sugar.
I'm saying do both. Make the cached version the one th
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > pg_migrator has become more popular recently, so it seems time to look
> > at some enhancements that would improve pg_migrator. None of these are
> > required, but rather changes that would be nice to have:
> >
> > 1) Right now pg_migrator preserv
On Thu, Dec 31, 2009 at 09:47:24AM -0800, David E. Wheeler wrote:
> On Dec 30, 2009, at 2:54 PM, Tim Bunce wrote:
>
> > That much works currently. Behind the scenes, when a stored procedure is
> > loaded into plperl the code ref for the perl sub is stored in a cache.
> > Effectively just
> >$c
David Fetter writes:
> On Tue, Jan 05, 2010 at 10:47:33AM -0500, Tom Lane wrote:
>> As pointed out here
>> http://archives.postgresql.org/pgsql-general/2010-01/msg00145.php
>> the current zic code doesn't cope gracefully with lack of working
>> int64. Considering the trouble we've gone to through
Andrew Dunstan writes:
> Something like:
> (my $bkival = $row->{bki_values}) =~ s/"[^"]*"/"xxx"/g;
> my $atts = {};
> @{$att...@attnames} = split /\s+/, $bkival;
> might work better.
I committed Alvaro's suggestion (undef at the bottom), but feel
free to clean it up if you like this w
Tom Lane wrote:
I'm not nearly good enough in Perl to be sure about the semantics
of this loop. Is it possible that it's changing the global contents
of the @$data structure, rather than just hacking a local copy of
each row before pushing some values into @fmgr?
That's exactly what it do
Stefan Kaltenbrunner writes:
>> What about Alvaro's idea of adding
>> $row = undef;
>> at the bottom of the loop? That seems marginally less ugly...
> not sure I want to argue about the ugliness of perl but that has the
> same effect as my patch so either way would do to get spoonbill green aga
Peter Eisentraut wrote:
On tis, 2010-01-05 at 10:14 -0800, Scott Bailey wrote:
One of the problem with shredding XML is that it is very kludgy to get a
scalar value back from xpath. The xpath function always returns an array
of XML. So for example, to extract a numeric value you need to:
1) us
Jeff Davis wrote:
> Clearly one of those transactions should abort, because that will
> happen in either serialized order. But I don't see where any lock
> is stored, nor how the conflict is detected.
That depends on where in the development cycle of this feature you
are. I'm anticipating tha
On Tue, Jan 5, 2010 at 2:14 PM, Jeff Davis wrote:
> I have a question regarding true serializability and predicate locking.
> There's some context on the wiki page:
>
> http://wiki.postgresql.org/wiki/Serializable
>
> under the heading "Predicate Locking".
>
> If you have the following DDL:
>
> c
Tom Lane wrote:
Stefan Kaltenbrunner writes:
yeah it is probably some strange platform specific issue - however with
some help from the IRC channel I came up with the following patch that
considerable reduces the memory bloat (but still needs ~55MB max) and
allows the build to succeed.
What
On Tue, Jan 05, 2010 at 02:02:51PM -0500, Tom Lane wrote:
> Stefan Kaltenbrunner writes:
> > did that and it seems the problem is in the loop that does:
>
> > foreach my $row (@$data)
> > {
>
> > # To construct fmgroids.h and fmgrtab.c, we need to inspect some
> > # of the individual d
Garick Hamlin writes:
> On Tue, Jan 05, 2010 at 02:02:51PM -0500, Tom Lane wrote:
>> I'm not nearly good enough in Perl to be sure about the semantics
>> of this loop. Is it possible that it's changing the global contents
>> of the @$data structure, rather than just hacking a local copy of
>> eac
Pavel Stehule wrote:
2010/1/5 Scott Bailey :
One of the problem with shredding XML is that it is very kludgy to get a
scalar value back from xpath. The xpath function always returns an array of
XML. So for example, to extract a numeric value you need to:
1) use xpath to get the node
2) get the f
On Tuesday, January 5, 2010, Peter Eisentraut wrote:
> On tis, 2010-01-05 at 16:48 +, Dave Page wrote:
>> On Tue, Jan 5, 2010 at 3:15 PM, Tom Lane wrote:
>> > I would have thought Microsoft would have a better solution than this
>> > for managing 64-bit libraries. Or am I too optimistic abou
Stefan Kaltenbrunner writes:
> yeah it is probably some strange platform specific issue - however with
> some help from the IRC channel I came up with the following patch that
> considerable reduces the memory bloat (but still needs ~55MB max) and
> allows the build to succeed.
What about Alvar
Tom Lane wrote:
Stefan Kaltenbrunner writes:
did that and it seems the problem is in the loop that does:
foreach my $row (@$data)
{
# To construct fmgroids.h and fmgrtab.c, we need to inspect some
# of the individual data fields. Just splitting on whitespace
Huh. It's weird
On tis, 2010-01-05 at 16:48 +, Dave Page wrote:
> On Tue, Jan 5, 2010 at 3:15 PM, Tom Lane wrote:
> > I would have thought Microsoft would have a better solution than this
> > for managing 64-bit libraries. Or am I too optimistic about Redmond's
> > competence?
>
> They have two separate ins
On tis, 2010-01-05 at 10:14 -0800, Scott Bailey wrote:
> One of the problem with shredding XML is that it is very kludgy to get a
> scalar value back from xpath. The xpath function always returns an array
> of XML. So for example, to extract a numeric value you need to:
> 1) use xpath to get the
I have a question regarding true serializability and predicate locking.
There's some context on the wiki page:
http://wiki.postgresql.org/wiki/Serializable
under the heading "Predicate Locking".
If you have the following DDL:
create table mytable(mycircle circle);
create index mytable_myci
Merlin Moncure wrote:
On Tue, Jan 5, 2010 at 1:14 PM, Scott Bailey wrote:
One of the problem with shredding XML is that it is very kludgy to get a
scalar value back from xpath. The xpath function always returns an array of
XML. So for example, to extract a numeric value you need to:
1) use xpat
Hi,
Kevin Grittner wrote:
Where would I find this (and any related documentation)?
Sorry, if that didn't get clear. I'm trying to put together something I
can release real soon now (tm). I'll keep you informed.
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@p
Stefan Kaltenbrunner escribió:
> foreach my $row (@$data)
> {
>
> # To construct fmgroids.h and fmgrtab.c, we need to inspect some
> # of the individual data fields. Just splitting on whitespace
> # won't work, because some quoted fields might contain internal
> # whitespace. We
Stefan Kaltenbrunner writes:
> did that and it seems the problem is in the loop that does:
> foreach my $row (@$data)
> {
> # To construct fmgroids.h and fmgrtab.c, we need to inspect some
> # of the individual data fields. Just splitting on whitespace
Huh. It's weird that I don't s
On Mon, 2010-01-04 at 08:04 +, Simon Riggs wrote:
> I would prefer this slightly modified version
>
> 1. Commit your patch, as-is (you/me)
I assume this is OK with you now?
--
Simon Riggs www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
On Tue, 2010-01-05 at 03:09 -0500, Tom Lane wrote:
> I think this can likely be blamed on the HS changes in transaction
> abort, since I'm not aware of any other recent changes near here.
I'll take a look.
--
Simon Riggs www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing list (
Tom Lane wrote:
Robert Haas writes:
Beats me. I don't have any other ideas at the moment.
Stefan, could you try adding some debugging printouts to the
Gen_fmgrtab.pl script to see how far it gets before blowing up?
did that and it seems the problem is in the loop that does:
foreach my $ro
Marko Tiikkaja writes:
> => with t as (delete from foo returning *)
> -> insert into bar
> -> select * from t;
> INSERT 0 2
> It correctly reports 2 affected rows (one deleted and one inserted), but
> is this the answer we want?
No. The returned tag should consider only the top-level operation
2010/1/5 Scott Bailey :
> One of the problem with shredding XML is that it is very kludgy to get a
> scalar value back from xpath. The xpath function always returns an array of
> XML. So for example, to extract a numeric value you need to:
> 1) use xpath to get the node
> 2) get the first element o
On Tue, Jan 5, 2010 at 1:14 PM, Scott Bailey wrote:
> One of the problem with shredding XML is that it is very kludgy to get a
> scalar value back from xpath. The xpath function always returns an array of
> XML. So for example, to extract a numeric value you need to:
> 1) use xpath to get the node
On Tue, Jan 5, 2010 at 1:20 PM, Tom Lane wrote:
> Robert Haas writes:
>> It's probably also worth noting that the reason I used DISTINCT
>> originally is because it's already a keyword.
>
> True.
>
> It occurs to me that the pg_stats view already exposes "n_distinct"
> as a column name. I wouldn
Robert Haas writes:
> It's probably also worth noting that the reason I used DISTINCT
> originally is because it's already a keyword.
True.
It occurs to me that the pg_stats view already exposes "n_distinct"
as a column name. I wouldn't object to using "n_distinct" and
"n_distinct_inherited" or
On Tue, Jan 5, 2010 at 1:09 PM, Robert Haas wrote:
> On Tue, Jan 5, 2010 at 1:00 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> Another option would be to call it "inherits_ndistinct", or something
>>> like that, which seems a little more readable, but not great: I don't
>>> think there's going
Robert Haas writes:
> Beats me. I don't have any other ideas at the moment.
Stefan, could you try adding some debugging printouts to the
Gen_fmgrtab.pl script to see how far it gets before blowing up?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hack
One of the problem with shredding XML is that it is very kludgy to get a
scalar value back from xpath. The xpath function always returns an array
of XML. So for example, to extract a numeric value you need to:
1) use xpath to get the node
2) get the first element of the XML array
3) cast that to
On Tue, Jan 5, 2010 at 1:00 PM, Tom Lane wrote:
> Robert Haas writes:
>> Another option would be to call it "inherits_ndistinct", or something
>> like that, which seems a little more readable, but not great: I don't
>> think there's going to be any getting around the need to RTFM before
>> settin
On Tue, Jan 5, 2010 at 12:51 PM, Tom Lane wrote:
> Robert Haas writes:
>> Is there by any chance some other, conflicting Catalog.pm on that machine?
>
> Even if there is, shouldn't the use of "perl -I" ensure our version gets
> loaded?
I would certainly think so.
> Also, Stefan's log shows that
Robert Haas writes:
> Another option would be to call it "inherits_ndistinct", or something
> like that, which seems a little more readable, but not great: I don't
> think there's going to be any getting around the need to RTFM before
> setting these parameters.
Well, the previously agreed-to syn
On Tue, Dec 29, 2009 at 9:12 PM, Tom Lane wrote:
> Robert Haas writes:
>> Yep. It would also lower the barrier to future innovations of that
>> type, which would be a good thing, IMO. Unfortunately we'd likely
>> need to continue to support the existing syntax at least for
>> attstattarget, whi
Robert Haas writes:
> Is there by any chance some other, conflicting Catalog.pm on that machine?
Even if there is, shouldn't the use of "perl -I" ensure our version gets
loaded?
Also, Stefan's log shows that it got through genbki.pl, so whatever the
problem is, I don't think it's Catalog.pm's fa
Robert Haas wrote:
On Tue, Jan 5, 2010 at 12:24 PM, Stefan Kaltenbrunner
wrote:
Tom Lane wrote:
Log Message:
---
Get rid of the need for manual maintenance of the initial contents of
pg_attribute, by having genbki.pl derive the information from the various
catalog header files. This g
On 2010-01-05 19:21 +0200, Greg Stark wrote:
with t as (delete from foo returning *)
select * from t where x=?
applications will almost certainly expect the number to match the
actual number of rows returned and may well misbehave if they don't.
I probably wasn't clear about the actual problem
On Tue, Jan 5, 2010 at 12:24 PM, Stefan Kaltenbrunner
wrote:
> Tom Lane wrote:
>>
>> Log Message:
>> ---
>> Get rid of the need for manual maintenance of the initial contents of
>> pg_attribute, by having genbki.pl derive the information from the various
>> catalog header files. This grea
Stefan Kaltenbrunner writes:
> this broke the build on spoonbill:
> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=spoonbill&dt=2010-01-05%2015:05:08
> manually executing the command shows that the perl process eats more
> than 250MB of RAM at closely afterwards fails with an out of mem
On Tue, Jan 05, 2010 at 05:21:12PM +, Greg Stark wrote:
> On Tue, Jan 5, 2010 at 4:42 PM, Marko Tiikkaja
> wrote:
> > => with t as (delete from foo returning *)
> > -> insert into bar
> > -> select * from t;
> > INSERT 0 2
> >
> > It correctly reports 2 affected rows (one deleted and one
> > i
Tom Lane wrote:
Log Message:
---
Get rid of the need for manual maintenance of the initial contents of
pg_attribute, by having genbki.pl derive the information from the various
catalog header files. This greatly simplifies modification of the
"bootstrapped" catalogs.
This patch finally
On Tue, Jan 5, 2010 at 4:42 PM, Marko Tiikkaja
wrote:
> => with t as (delete from foo returning *)
> -> insert into bar
> -> select * from t;
> INSERT 0 2
>
> It correctly reports 2 affected rows (one deleted and one inserted), but is
> this the answer we want? It doesn't seem all that useful to
On Tue, Jan 5, 2010 at 3:15 PM, Tom Lane wrote:
> Dave Page writes:
>> After chatting with Magnus, we feel that a good solution would be to
>> rename libpq on Win64 to libpq64.dll to distinguish it from the 32 bit
>> equivalent.
>
> Isn't that going to break applications? Where by "break" I mean
On Mon, Jan 04, 2010 at 02:32:56PM -0500, Tom Lane wrote:
> I think checking SIZEOF_LONG would be preferred, since that's what
> we use elsewhere. Although actually I wonder why this code exists
> at all --- wouldn't it be easier to make these depend on "int64"?
It does use int64. However, ecpg u
On Mon, Jan 04, 2010 at 07:39:14PM +0100, Boszormenyi Zoltan wrote:
> new patch attached.
> ...
Great job Zoltan, committed.
> The sqlda.h header switches between the two different
> structures depending on a new #define introduced in
> and added to the generated C source by the preprocessor
I c
Markus Wanner wrote:
> Kevin Grittner wrote:
>> It's very soon going to be critical that I be able to test
>> particular interleavings of statements in particular concurrent
>> transaction sets to be able to make meaningful progress on the
>> serializable transaction work.
>
> I've something in
Magnus Hagander wrote:
On Thu, Dec 31, 2009 at 00:57, Magnus Hagander wrote:
2009/12/31 Hiroshi Inoue :
Magnus Hagander wrote:
2009/12/30 Hiroshi Inoue :
Hi,
As far as I tested, the krb_server_keyfile setting
in postgres.conf doesn't work on Windows.
Because gssapi32.dll(krb5_32.dll) seems
Tom Lane wrote:
> Robert Haas writes:
> > On Tue, Jan 5, 2010 at 11:06 AM, Alvaro Herrera
> > wrote:
> >> Tom Lane wrote:
> >>> Good point. ?Using catversion for the purpose seems a bit ugly but
> >>> I have no better ideas.
> >>
> >> I thought we had rejected the idea of being able to migrate b
On Tue, Jan 05, 2010 at 10:47:33AM -0500, Tom Lane wrote:
> As pointed out here
> http://archives.postgresql.org/pgsql-general/2010-01/msg00145.php
> the current zic code doesn't cope gracefully with lack of working
> int64. Considering the trouble we've gone to throughout the rest of
> the system
Robert Haas writes:
> On Tue, Jan 5, 2010 at 11:06 AM, Alvaro Herrera
> wrote:
>> Tom Lane wrote:
>>> Good point. Using catversion for the purpose seems a bit ugly but
>>> I have no better ideas.
>>
>> I thought we had rejected the idea of being able to migrate between
>> alphas. Is migrating
On Tue, Jan 5, 2010 at 11:06 AM, Alvaro Herrera
wrote:
> Tom Lane wrote:
>> Bruce Momjian writes:
>> > I liked the idea, but I listed it as item #2 and no one else said they
>> > liked it. The only complexity I can see with the idea is that doing an
>> > upgrade from one alpha to another would h
Tom Lane wrote:
> Bruce Momjian writes:
> > I liked the idea, but I listed it as item #2 and no one else said they
> > liked it. The only complexity I can see with the idea is that doing an
> > upgrade from one alpha to another would have the same major version
> > number and would therefore not
On Tue, Jan 5, 2010 at 10:45 AM, Leonardo F wrote:
>> As you say, there's really no point in changing the internal
>> representation, and if you don't find replace() useful either, then
>> why are you even working on this at all?
>
> I would like a get_bit / set_bit for bit strings, as I find them
Tom Lane wrote:
> As pointed out here
> http://archives.postgresql.org/pgsql-general/2010-01/msg00145.php
> the current zic code doesn't cope gracefully with lack of working
> int64. Considering the trouble we've gone to throughout the rest
> of the system to support such compilers, it's a bit ann
Bruce Momjian writes:
> I liked the idea, but I listed it as item #2 and no one else said they
> liked it. The only complexity I can see with the idea is that doing an
> upgrade from one alpha to another would have the same major version
> number and would therefore not be possible, so maybe we h
As pointed out here
http://archives.postgresql.org/pgsql-general/2010-01/msg00145.php
the current zic code doesn't cope gracefully with lack of working
int64. Considering the trouble we've gone to throughout the rest
of the system to support such compilers, it's a bit annoying to
have this little
> As you say, there's really no point in changing the internal
> representation, and if you don't find replace() useful either, then
> why are you even working on this at all?
I would like a get_bit / set_bit for bit strings, as I find them useful.
get_bit could be a simple call to substring, bu
Peter Eisentraut writes:
> On mån, 2010-01-04 at 21:58 -0500, Tom Lane wrote:
>> The new implementation uses temp files that just have ".tmp" appended to
>> the target file name. If there is a risk that "make -j" will run the
>> same action twice in parallel, this isn't good enough. While it
>>
On mån, 2010-01-04 at 22:54 -0500, Robert Haas wrote:
> I think you're dismissing the idea too cavalierly. If A generates B,
> A is inevitably changed frequently, but the changes to A affect B only
> rarely, this is a good trick.
If that is the case, you might want to consider splitting up A or
Robert Haas writes:
> On Tue, Jan 5, 2010 at 12:56 AM, black light wrote:
>> In fact, i want to add a table to system catalog and SELECT/UPDATE it from
>> auth.c.
> If you are considering proposing your patch for inclusion in the
> PostgreSQL upstream sources, you should first discuss why you ar
Tom Lane wrote:
> Bruce Momjian writes:
> > Alvaro Herrera wrote:
> >> I thought it was impossible to use bare mountpoints as tablespaces due
> >> to ownership problems ... Is that not the case? -1 for special hacks
> >> that work around bogus setups, if that means intrusive changes to the
> >> c
On mån, 2010-01-04 at 21:58 -0500, Tom Lane wrote:
> The old Gen_fmgrtab.sh script used temporary file names that included
> its process PID. It had this comment about that:
>
> # We use the temporary files to avoid problems with concurrent runs
> # (which can happen during parallel make).
>
> T
On Mon, Jan 4, 2010 at 1:48 PM, Tom Lane wrote:
> Robert Haas writes:
>> My only objection to that is that if we're going to add attoptions
>> also, I'd like to get this committed first before I start working on
>> that, and we're running short on time. If you can commit his patch in
>> the next
Dave Page writes:
> After chatting with Magnus, we feel that a good solution would be to
> rename libpq on Win64 to libpq64.dll to distinguish it from the 32 bit
> equivalent.
Isn't that going to break applications? Where by "break" I mean
"have to explicitly link with 'libpq64', thereby renderi
1 - 100 of 124 matches
Mail list logo
