On Mon, 10 Mar 2008, Tom Lane wrote:
I am wondering if these checks have been no-ops in Postgres builds done
with gcc 4.1 and up, and we're only just now being told about it.
Since gcc 4.2 supports -Wstrict-overflow, I rebuilt pg with that to see
what it's doing currently. I'm not sure w
On Sun, 9 Mar 2008, Tom Lane wrote:
Simon Riggs <[EMAIL PROTECTED]> writes:
I've coded a small patch to allow CaseSensitive synonyms.
Applied with corrections (it'd be good if you at least pretended to test
stuff before submitting it).
Would a similar parameter be useful for any of the other
Kris Jurka <[EMAIL PROTECTED]> writes:
> Gcc 4.3 has started to perform optimizations based on the denial of the
> existence of signed overflow. Building CVS HEAD with gcc 4.3rc2 I get the
> following warnings:
Hmm, I suspect that it's not so much that they're performing new
optimizations as tha
A while back Tom Lane presented the potential problem with gcc signed
overflow handling, but now it's not just a theoretical problem.
http://archives.postgresql.org/pgsql-hackers/2005-12/msg00635.php
Gcc 4.3 has started to perform optimizations based on the denial of the
existence of signed
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Thu, 2007-12-13 at 22:23 -0800, Neil Conway wrote:
>> If "LIMIT n" means "emit at most n tuples", then a query that produces 0
>> rows with n < 0 is arguably violating its spec, since it has produced
>> more tuples than the LIMIT specified (0 > n). Inter
Simon Riggs <[EMAIL PROTECTED]> writes:
> I've coded a small patch to allow CaseSensitive synonyms.
Applied with corrections (it'd be good if you at least pretended to test
stuff before submitting it).
Would a similar parameter be useful for any of the other dictionary
types?
Tom Lane wrote:
> I've gone through the patch queue and marked all or at least most of
> the threads that don't contain any commit-fest material. (The remaining
> threads contain actual patches, or at least design discussions that seem
> worth getting more eyeballs on at the present time.) Could
"Bruce Momjian" <[EMAIL PROTECTED]> writes:
> Decibel! wrote:
>> On Feb 26, 2008, at 4:36 PM, Tom Lane wrote:
>> > I think a sane way to think about what Simon would like to accomplish
>> > is not "turn psql into a parallel job scheduler"
>>
>>
>> My $0.02: I often find myself wishing I could pe
>>conveniences of the backend coding environment in a frontend application
I don't think this is required. I'm thinking about light-weight wrappers around
A-2-B style converters, no ties to the backend or client. A free standing util
library. The idea doesn't require a backend environment.
Michael Meskes <[EMAIL PROTECTED]> writes:
>>> As long as both implementations are kept in sync I don't see a reason.
>>
>> Sharing the backend data type converters with client stuff is an obvious
>> win, but its a tedious process probably lacking any motivation. We did
>> look at it though, it
I've gone through the patch queue and marked all or at least most of
the threads that don't contain any commit-fest material. (The remaining
threads contain actual patches, or at least design discussions that seem
worth getting more eyeballs on at the present time.) Could you pull out
all that st
I wrote:
> I have a field whose distribution of frequencies of values is
> roughly geometric, rather than flat.
> Total rows = 36 million
> relpages=504864
> Distinct field values in use = 169
> 10 values account for 50% of the rows.
> 41 values account for 90% of the rows.
>
> After setting stat
On Sun, Mar 9, 2008 at 7:25 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "=?ISO-8859-2?Q?Micha=B3_Zaborowski?=" <[EMAIL PROTECTED]> writes:
> > I would like to be able to add CONSTRAINT and/or DEFAULT with out
> > affecting old rows.
>
> You mean without actually checking that the old rows satisfy
Tom Lane wrote:
> Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
> > On Fri, Mar 07, 2008 at 07:25:25PM +0100, Peter Eisentraut wrote:
> >> What's the problem with setting it to ten million if I
> have ten million values
> >> in the table and I am prepared to spend the resources to
> maintai
>>I thought we were just talking about some definitions.
I was expanding on your "#1" question, which was directly talking about "shared"
headers rather than just cleaning out HAVE_INT64_TIMESTAMP. I had the same
experience but also ran into the need for "shared" library code; which BTW ecpg
> >> As long as both implementations are kept in sync I don't see a reason.
>
> Sharing the backend data type converters with client stuff is an obvious
> win, but its a tedious process probably lacking any motivation. We did
> look at it though, it is possible.
I thought we were just talking a
"=?ISO-8859-2?Q?Micha=B3_Zaborowski?=" <[EMAIL PROTECTED]> writes:
> I would like to be able to add CONSTRAINT and/or DEFAULT with out
> affecting old rows.
You mean without actually checking that the old rows satisfy the
constraint? There's approximately zero chance that that proposal
will be a
On Fri, Mar 7, 2008 at 3:51 PM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
~> Jim C. Nasby wrote:
> > On Wed, Jul 04, 2007 at 01:03:20PM +0200, Dawid Kuroczko wrote:
> > > Hello.
> > >
> > > I think it could be a nice idea to put descriptions from
> > > http://www.postgresql.org/docs/8.2/static/c
Michael Meskes wrote:
On Sun, Mar 09, 2008 at 12:32:20AM -0800, Warren Turkal wrote:
1) Is there a reason that header information is duplicated between normal
posgresql include and ecpg includes instead of defining the info in one place
and #including it into the files that need it?
Merlin and
Hello,
I would like to be able to add CONSTRAINT and/or DEFAULT with out
affecting old rows. Yes, it sounds strange, but... Let's say I have
big table, I want to add new column, with DEFAULT and NOT NULL.
Normally it means long exclusive lock. So - right now I'm adding plain
new column, then DEFAU
On Sun, Mar 09, 2008 at 12:32:20AM -0800, Warren Turkal wrote:
> 1) Is there a reason that header information is duplicated between normal
> posgresql include and ecpg includes instead of defining the info in one place
> and #including it into the files that need it?
As long as both implementation
PosgreSQL hackers,
Here's an initial bit of my attempt at cleaning up the the timestamp datatype.
I have gone through the backend and made a couple small changes to stop using
the HAVE_INT64_TIMESTAMP define to select a type in code by creating typedefs
in a header and using the typedef in the cod
I added TimeOffset and DateOffset typedefs to get rid of the instances
using the HAVE_INT64_TIMESTAMP define being used to determine the
types of variables or functions in timestamp.c.
---
src/backend/utils/adt/timestamp.c | 77 +++-
src/include/utils/timestamp.h
I have removed all instances of using HAVE_INT64_TIMESTAMP to determine the
type of a variable in files depending on timestamp.h.
---
src/backend/utils/adt/nabstime.c |6 +-
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/src/backend/utils/adt/nabstime.c b/src/backend/utils/
PosgreSQL hackers,
Here's an initial bit of my attempt at cleaning up the the timestamp datatype.
I have gone through the backend and made a couple small changes to stop using
the HAVE_INT64_TIMESTAMP define to select a type in code by creating typedefs
in a header and using the typedef in the cod
25 matches
Mail list logo
