Tom Lane wrote:
ISTR that we had patch-merging problems too, because any patch
submitters who took it seriously were trying to patch the same chunk
of release.sgml.
That could be annoying, yes. I'm not sure how serious a problem it would
be in practice -- we could always adopt workarounds like
Bruce Momjian wrote:
Also, we are having trouble getting enough people to review/commit.
Does adding an extra step discourage them even further?
I think if you are committing a patch, you should have a clear idea of
what the patch does and what its broader impact on the system will be.
Summar
Bruce Momjian wrote:
Another complexity is that when you are going through the logs in 1-3
days, you remember all the information and can adjust things so they are
consistent. I have certain rules of determining what items are worthy,
what are not, and what have to be merged into a single entry.
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> This patch allows using any row expression in return statement and does
> transformation from untyped row to composite types if it's necessary.
This patch doesn't seem to cope with cases where the supplied tuple has
the wrong number of columns, and i
Sent to pgsql-sql now.
--
Andreas Joseph Krogh <[EMAIL PROTECTED]>
Senior Software Developer / Manager
gpg public_key: http://dev.officenet.no/~andreak/public_key.asc
+-+
OfficeNet AS| The most difficult thing in the
I have the following query:
select lower(firstname) || ' ' || lower(lastname) from person
firstname and lastname are VARCHAR
lower() returns NULL when firstname OR lastname is NULL, is this correct?
This is 8.2devel from 24.08.2006.
--
Andreas Joseph Krogh <[EMAIL PROTECTED]>
Senior Software
This works as intended. Try this:
select coalesce(lower(firstname), '') || ' ' || coalesce(lower(lastname), '')
from person
Concating something unknown (=NULL) and a string = unknown (=NULL)
-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Andre
>> I tried to build postgresql from src using vc++ 2005 but was
>not able to go
>> far before hitting errors related to inline function in the
>"wchar.c" file.
>>
>> The source file I downloaded is "postgresql-8.1.4.tar.gz".
>I tried to build
>> it by runing "nmake -f win32.mak" in the "src" d
Gregory Stark wrote:
It's limited but I wouldn't say it's very limiting. In the cases where it
doesn't apply there's no way out anyways. A UTF8 field will need a length
header in some form.
Actually, you can determine the length of a UTF-8 encoded character by
looking at the most significant b
On Thu, Sep 14, 2006 at 01:56:16PM -0700, Josh Berkus wrote:
> Darcy,
>
> > The biggest argument about the money type is that it has an unrealistic
> > limit.
>
> Funny, I thought it was the lack of operators, conversions and any clear plan
> on how to have a money type that supports multiple c
On Thu, Sep 14, 2006 at 06:25:42PM -0400, Tom Lane wrote:
> Jeff Davis <[EMAIL PROTECTED]> writes:
> > How would creating a new lock type avoid deadlocks when an ANALYZE is
> > accumulating the locks in random order?
>
> In itself it wouldn't. Josh Drake sketched the idea in more detail
> later:
On Fri, Sep 15, 2006 at 10:01:19AM +0100, Heikki Linnakangas wrote:
> Gregory Stark wrote:
> >It's limited but I wouldn't say it's very limiting. In the cases where it
> >doesn't apply there's no way out anyways. A UTF8 field will need a length
> >header in some form.
>
> Actually, you can determi
On 2006-09-15, Martijn van Oosterhout wrote:
> Ofcorse, if this is a faster numeric type,
Presumably the same speed as bigint, which is to say that while it is
faster than numeric for calculation, it is (much) slower for input/output.
(The difference in speed between bigint output and numeric out
Hi, Tom,
Tom Lane wrote:
> We could add another LockTagType just for ANALYZE, but that seems like
> rather a lot of infrastructure to support an extremely narrow corner
> case, namely two people doing database-wide ANALYZE at the same time
> inside transaction blocks. (If they do it outside a tra
Martijn van Oosterhout wrote:
On Fri, Sep 15, 2006 at 10:01:19AM +0100, Heikki Linnakangas wrote:
Actually, you can determine the length of a UTF-8 encoded character by
looking at the most significant bits of the first byte. So we could
store a UTF-8 encoded CHAR(1) field without any additional
On Fri, Sep 15, 2006 at 11:43:52AM +0100, Heikki Linnakangas wrote:
> My gut feeling is that it wouldn't be that bad compared to what we have
> now or the new proposed varlena scheme, but before someone actually
> tries it and shows some numbers, this is just hand-waving.
Well, that depends on w
Martijn van Oosterhout wrote:
I don't think making a special typlen value just for a type that can
store a single UTF-8 character is smart. I just can't see enough use to
make it worth it.
Assuming that we can set encoding per-column one day, I agree. If you
have a CHAR(1) field, you're goi
What about the "char" type? Isn't it designed for that? Or will this type
disappear in future releases?
-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Heikki
Linnakangas
Gesendet: Freitag, 15. September 2006 13:35
An: Martijn van Oosterhout
Cc
On Fri, Sep 15, 2006 at 01:38:54PM +0200, Mario Weilguni wrote:
> What about the "char" type? Isn't it designed for that? Or will this type
> disappear in future releases?
"char" is used in the system catalogs, I don't think it's going to go
any time soon.
There it's used as a (surprise) single
Martijn van Oosterhout writes:
> I don't think making a special typlen value just for a type that can
> store a single UTF-8 character is smart. I just can't see enough use to
> make it worth it.
Well there are lots of data types that can probably tell how long they are
based on internal state.
On 2006-09-15, Markus Schaber <[EMAIL PROTECTED]> wrote:
> Is there any reason to allow ANALYZE run insinde a transaction at all?
Absolutely. In a large transaction that radically changes the content of
the database, it is often necessary to analyze in order to avoid getting
extremely bad query pl
Hi, Andrew,
Andrew - Supernews wrote:
>> Is there any reason to allow ANALYZE run insinde a transaction at all?
>
> Absolutely. In a large transaction that radically changes the content of
> the database, it is often necessary to analyze in order to avoid getting
> extremely bad query plans for
Markus Schaber <[EMAIL PROTECTED]> writes:
> Is there any reason to allow ANALYZE run insinde a transaction at all?
I had a script to run explain over a set of queries, then run analyze, then
run explain again and check the plans for unexpected changes. It would roll
back the analyze if any prod
Martijn van Oosterhout writes:
> For stuff run from autovacuum, would it be reasonable for the
> automatically run version to just abort if it sees someone doing the
> same thing?
Not especially --- there's no guarantee that the other guy is going to
commit at all. And autovac is only holding on
Neil Conway <[EMAIL PROTECTED]> writes:
> Bruce Momjian wrote:
>> How is maintaining another file on every commit going to go over?
> Well, it would clearly not be on every commit: most commits don't
> warrant a mention in the release notes. If committers think that this
> burden is too much to
I've send the comment below to the documentation page about CREATE
FUNCTION, but it got (rightfully) rejected, since it doesn't really
add up to the discussion and is more of a request about syntax. So,
here it goes:
Sorry, but "datetime" vs "timestamp with time zone"?! And what about
the whole
Tom Lane wrote:
If *someone else* wants to troll the commit logs every so often and make
entries into release.sgml, that's fine with me. But I don't have the
bandwidth.
IIRC this was suggested upthread as a task that might be suitable for
some people who are less on the critical
Please, take this as constructive criticism, since i'm a proud
open-source supporter... i would gladly use PostgreSQL at work,
clunkier syntax or not, but it's otherwise difficult to sell it to my
Windows-minded coworkers...
I would love to take this as constructive criticism, but you haven't
Tom Lane <[EMAIL PROTECTED]> writes:
> Well, I'm willing to (and I think usually have) put release-note-grade
> descriptions into commit log messages, but I'm not willing to add "edit
> release.sgml" to the already long process, for two basic reasons:
>
> * it'd make release.sgml into a commit bo
"Ricardo Malafaia" <[EMAIL PROTECTED]> writes:
> Sorry, but "datetime" vs "timestamp with time zone"?! And what about
> the whole function text between $$'s? Yes, better than the '' of some
> time ago, since we don't have to put string literals in the function
> text between 's! still...
"ti
Ricardo Malafaia wrote:
I've send the comment below to the documentation page about CREATE
FUNCTION, but it got (rightfully) rejected, since it doesn't really
add up to the discussion and is more of a request about syntax. So,
here it goes:
Sorry, but "datetime" vs "timestamp with time zone"?!
Gregory Stark <[EMAIL PROTECTED]> writes:
> Well we could make it "edit release.txt" which someone will fix up and turn
> into release.sgml later instead.
> I think if you put a big enough separator between entries, say two black
> lines, two dashes, and two more blank lines, it wouldn't even caus
> I suspect that up to now the buildfarm had a static build of
> PostgreSQL. What is the output of 'ldd initdb' when it builds
> and runs correctly?
>
> Is libpq.so in a non-standard directory? If yes, one either
> has to export LIBPATH in the environment or link with
> -L/location/of/libpq for th
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
>> This patch doesn't seem to cope with cases where the supplied tuple has
>> the wrong number of columns, and it doesn't look like it's being careful
>> about dropped columns either. Also, that's a mighty bizarre-looking
>> choice of cache memory contex
On Fri, 15 Sep 2006 10:17:55 -
Andrew - Supernews <[EMAIL PROTECTED]> wrote:
> Presumably the same speed as bigint, which is to say that while it is
> faster than numeric for calculation, it is (much) slower for input/output.
> (The difference in speed between bigint output and numeric output i
On Thu, 14 Sep 2006 14:12:30 -0400
AgentM <[EMAIL PROTECTED]> wrote:
> If you force the locale into the money type, then the entire column
> must be of the same currency. That seems like an unnecessary
> limitation. Does your type support banker's rounding?
The whole point of money is to have
Rocco Altier wrote:
> Here is the working one:
> initdb needs:
> /usr/lib/libc.a(shr.o)
> /unix
> /usr/lib/libcrypt.a(shr.o)
>
> Here is the broken one:
> initdb needs:
> ../../../src/interfaces/libpq/libpq.so
> /usr/lib/libc.a(shr.o)
> /usr/li
On 2006-09-15, "D'Arcy J.M. Cain" wrote:
> On Fri, 15 Sep 2006 10:17:55 -
> Andrew - Supernews <[EMAIL PROTECTED]> wrote:
>> Presumably the same speed as bigint, which is to say that while it is
>> faster than numeric for calculation, it is (much) slower for input/output.
>> (The difference in
"Albe Laurenz" <[EMAIL PROTECTED]> writes:
> Up to now you have built against the static libpq.a
> I didn't add the right -blibpath to this patch that
> failed for you - the broken initdb is dynamically linked
> but does not know where to look for its shared library.
> The patch I just submitted t
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> "Albe Laurenz" <[EMAIL PROTECTED]> writes:
> > Up to now you have built against the static libpq.a
> > I didn't add the right -blibpath to this patch that
> > failed for you - the broken initdb is dynamically linked
> > but does not know where to look f
well, ain't that surprising to see so many open-source developers
living in denial and sugestions to RTFM rather than actually coping
wth the problem? are you to be taken seriously?
As a C programmer, I'm in the same league as most of you guys, so
while i can really contribute code and my talk i
I'm reading the code in tqual.c and find that this comment doesn't seem to
match the code. CommandId always seems to be compared with >= or <= rather
than equality as the comment says.
I'm not even sure I have these operators right as the expression as written
here is in a few places the convers
On Fri, 15 Sep 2006 15:14:10 -
Andrew - Supernews <[EMAIL PROTECTED]> wrote:
> On 2006-09-15, "D'Arcy J.M. Cain" wrote:
> > On Fri, 15 Sep 2006 10:17:55 -
> > Andrew - Supernews <[EMAIL PROTECTED]> wrote:
> >> Presumably the same speed as bigint, which is to say that while it is
> >> faste
On Fri, Sep 15, 2006 at 12:35:03PM -0300, Ricardo Malafaia wrote:
> On 9/15/06, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
> >Where is the mention of either of these on the CREATE FUNCTION page?
>
> http://www.postgresql.org/docs/8.1/interactive/sql-createfunction.html
Err, in the example? So you'
Sweet! I'll try it as soon as it's available.Xiaofeng Zhaohttp://www.xzing.orgerrare humanum est> Subject: Re: [HACKERS] Build v8.1.4 with VC++ 2005> Date: Fri, 15 Sep 2006 10:59:03 +0200> From: [EMAIL PROTECTED]> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]> CC: pgsql-hackers@postgresql.org> > >> I
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Ricardo Malafaia
> Sent: 15 September 2006 16:35
> To: Andrew Dunstan
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] polite request about syntax
>
> my complaint is that, like i said
The only person in denial is you. Here's a hard lesson about open
source: bitching gets you nothing.
YOU are not going to be taken seriously while all you do is complain.
And if you must complain, make sure the politeness is in the words, not
just the subject.
The only place timestamp is m
"Ricardo Malafaia" <[EMAIL PROTECTED]> writes:
> my complaint is that, like i said, "timestamp with time zone" is no
> good substitute for a simple "datetime". Here, someone suggested a
> CREATE DOMAIN to create an alias for it. Why isn't it provided there
> out-of-the-box by default? So you hav
Andrew - Supernews wrote:
> Numbers from an actual benchmark:
>
> int4out(0) - 0.42us/call
> numeric_out(0) - 0.32us/call
>
> int4out(10) - 0.67us/call
> numeric_out(10) - 0.42us/call
Is this really int4out, or is it int8out?
--
Alvaro Herrera
Gregory Stark <[EMAIL PROTECTED]> writes:
> I'm reading the code in tqual.c and find that this comment doesn't seem to
> match the code. CommandId always seems to be compared with >= or <= rather
> than equality as the comment says.
Yeah, you're right, the comment seems to be written on the assump
On 2006-09-15, "D'Arcy J.M. Cain" wrote:
>> Seems? Have you benchmarked it?
>
> Not rigourously but a few "ANALYZE EXPLAIN" statements bear out this
> observation.
The overhead of EXPLAIN ANALYZE is so large that it completely swamps any
real difference.
>> The point is that bigint is _not_ fast
On 2006-09-15, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Andrew - Supernews wrote:
>> Numbers from an actual benchmark:
>>
>> int4out(0) - 0.42us/call
>> numeric_out(0) - 0.32us/call
>>
>> int4out(10) - 0.67us/call
>> numeric_out(10) - 0.42us/call
>
> Is this really int4
-- Forwarded message --
From: Ricardo Malafaia <[EMAIL PROTECTED]>
Date: Sep 15, 2006 1:28 PM
Subject: Re: [HACKERS] polite request about syntax
To: Tom Lane <[EMAIL PROTECTED]>
ok, guys. i guess i was a bit unfair. Timestamp is used everywhere
indeed, Oracle, Firebird you name
I've been looking at doing the following TODO item:
Allow ORDER BY ... LIMIT # to select high/low value without sort or index
using a sequential scan for highest/lowest values
Right now, if no index exists, ORDER BY ... LIMIT # requires we sort all
values to return the high/low v
"Ricardo Malafaia" <[EMAIL PROTECTED]> writes:
> What happens then when it sees something like a double variable
> interpolation as in $$foobar? ;)
Then you use $FOO$ (or something else that doesn't appear in your
code) as the delimiter--you're not limited to just $$.
-Doug
On Fri, 15 Sep 2006 16:15:24 -
Andrew - Supernews <[EMAIL PROTECTED]> wrote:
> On 2006-09-15, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> > Andrew - Supernews wrote:
> >> Numbers from an actual benchmark:
> >>
> >> int4out(0) - 0.42us/call
> >> numeric_out(0) - 0.32us/call
> >>
> >> int4o
On 9/15/06, Douglas McNaught <[EMAIL PROTECTED]> wrote:
> What happens then when it sees something like a double variable
> interpolation as in $$foobar? ;)
Then you use $FOO$ (or something else that doesn't appear in your
code) as the delimiter--you're not limited to just $$.
clever. still,
Ricardo Malafaia wrote:
And the $$ is indeed needed for allowing languages with different
syntaxes. agreed. However, Tom, i could counter example your plperl
example:
realize that qq/end/ does not represent a matching "end"?
What happens then when it sees something like a double variable
i
Ricardo Malafaia wrote:
> On 9/15/06, Douglas McNaught <[EMAIL PROTECTED]> wrote:
> >> What happens then when it sees something like a double variable
> >> interpolation as in $$foobar? ;)
> >
> >Then you use $FOO$ (or something else that doesn't appear in your
> >code) as the delimiter--you're not
On Fri, 15 Sep 2006 16:15:04 -
Andrew - Supernews <[EMAIL PROTECTED]> wrote:
> On 2006-09-15, "D'Arcy J.M. Cain" wrote:
> >> Seems? Have you benchmarked it?
> >
> > Not rigourously but a few "ANALYZE EXPLAIN" statements bear out this
> > observation.
>
> The overhead of EXPLAIN ANALYZE is so
Gregory Stark <[EMAIL PROTECTED]> writes:
> I've been looking at doing the following TODO item:
> Allow ORDER BY ... LIMIT # to select high/low value without sort or index
> using a sequential scan for highest/lowest values
> I think this is pretty important to cover at some point because
Abhijit Menon-Sen <[EMAIL PROTECTED]> writes:
> At 2006-09-05 16:35:49 -0400, [EMAIL PROTECTED] wrote:
>> So basically I don't see the point of investing effort in a
>> bug-compatible version of userlocks, when we can have something
>> cleaner and suitable for the long run with not very much more
>
Tom Lane wrote:
(unless we want to invent aggregates that can return SETOF?)
Doesn't sound like a bad idea at all ...
cheers
andrew
---(end of broadcast)---
TIP 6: explain analyze is your friend
"Nikolay Samokhvalov" <[EMAIL PROTECTED]> writes:
> On 8/26/06, Peter Eisentraut <[EMAIL PROTECTED]> wrote:
>> "Valid" and "well-formed" have very specific distinct meanings in XML.
>> (Note that "check" doesn't have any meaning there.) We will eventually
>> want a method to verify both the validi
I would like to create some regression tests for the uuid datatype.
Should those also be included in the patch to review or the regression
tests are done by the commiters?
Regards,
Gevik.
---(end of broadcast)---
TIP 6: explain analyze is your frie
Gevik Babakhani wrote:
I would like to create some regression tests for the uuid datatype.
Should those also be included in the patch to review or the regression
tests are done by the commiters?
In the patch.
cheers
andrew
---(end of broadcast)
Following up on the recent discussion on list about wasted space in data
representations I want to summarise what we found and make some proposals:
As I see it there are two cases:
Case 1) Data types that are variable length but often quite small. This includes
things like NUMERIC which in c
> > From: Tom Lane [mailto:[EMAIL PROTECTED]
> > Mmm ... what of "make check"'s temporary installation? We need
> > to have the executables search in the temporary install's libdir,
> > *before* looking in the configured --libdir (which could easily
> > contain an incompatible back-version libpq
With the patch attached this time...
-rocco
> -Original Message-
> From: Rocco Altier
> Sent: Friday, September 15, 2006 2:04 PM
> To: Rocco Altier; 'Tom Lane'; 'Albe Laurenz'
> Cc: 'pgsql-hackers@postgresql.org'
> Subject: RE: [PATCHES] [HACKERS] Linking on AIX (Was: Fix
> link
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> That does not mean that the patch is bad, and I certainly support the
> feature change. But I can't efficiently review the patch. If someone
> else wants to do it, go ahead.
I've finally taken a close look at this patch, and I don't like it any
mo
On Fri, Sep 15, 2006 at 06:50:37PM +0100, Gregory Stark wrote:
> With a CHAR(1) and CASH style numeric substitute we won't have 25-100%
> performance lost on the things that would fit in 1-4 bytes. And with the
> variable sized varlena header we'll limit to 25% at worst and 1-2% usually the
> perfo
Tom Lane <[EMAIL PROTECTED]> writes:
> I believe a better way to think about this would be as an aggregate that
> remembers the top N rows.
Wouldn't such a thing just be a reimplementation of a tuplestore though? I
mean, it's storing tuples you feed it, sorting them, and spitting them back
out
Hello,
Yeah, this is a cross post and it is slightly off topic but IMHO this is
important.
Tomorrow one of our own, Devrim Gunduz is becoming a man. He is sucking
it up, and committing to the cvs repo of project marriage.
May the patches reviewers be kind to him!
Congratz Devrim, have a go
On Fri, Sep 15, 2006 at 05:30:27PM +0100, Gregory Stark wrote:
> Also, because heap sort is slower than qsort (on average anyways) it makes
> sense to not bother with the heap until the number of tuples grows well beyond
> the limit or until it would otherwise spill to disk.
The thought that comes
Tom Lane <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>
>> I think this is pretty important to cover at some point because really _not_
>> doing this just wrong.
>
> I can't get all *that* excited about it, since an index solves the
> problem.
Well I'm not all *that* ex
Gregory Stark wrote:
> Tom Lane <[EMAIL PROTECTED]> writes:
>
> > I believe a better way to think about this would be as an aggregate that
> > remembers the top N rows.
>
> Wouldn't such a thing just be a reimplementation of a tuplestore though? I
> mean, it's storing tuples you feed it, sortin
Tom Lane wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > Bruce Momjian wrote:
> >> How is maintaining another file on every commit going to go over?
>
> > Well, it would clearly not be on every commit: most commits don't
> > warrant a mention in the release notes. If committers think that th
Martijn van Oosterhout writes:
> On Fri, Sep 15, 2006 at 05:30:27PM +0100, Gregory Stark wrote:
>> Also, because heap sort is slower than qsort (on average anyways) it makes
>> sense to not bother with the heap until the number of tuples grows well
>> beyond
>> the limit or until it would other
I have completed my first pass over the release notes and Tom has made
some additions:
http://momjian.postgresql.org/cgi-bin/pgrelease
I will probably go over them again in a few hours, update them to
current CVS, then move them into our SGML documentation by Monday.
--
Bruce Momjian
I would like to see some comments about AIX linking so we don't need to
relearn this in 1-2 years.
---
Rocco Altier wrote:
> With the patch attached this time...
>
> -rocco
>
> > -Original Message-
> > From:
On Fri, Sep 15, 2006 at 08:22:50PM +0100, Gregory Stark wrote:
> But just in case it's not clear for anyone the usual use case for
> this paging results on a web page. As much as I normally try to
> convince people they don't want to do it that way they usually do
> end up with it implemented using
OK, patch sent to the 8.3 hold queue for later work, open item removed.
---
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > That does not mean that the patch is bad, and I certainly support the
> > featur
On 9/15/06, Bruce Momjian <[EMAIL PROTECTED]> wrote:
I have completed my first pass over the release notes and Tom has made
some additions:
http://momjian.postgresql.org/cgi-bin/pgrelease
In Server changes, the two first lines are:
# Improve performance of statistics monitoring, espec
[EMAIL PROTECTED] writes:
> On Fri, Sep 15, 2006 at 08:22:50PM +0100, Gregory Stark wrote:
>
> I'm curious, as I may be such an offender. What alternatives exist?
>
> I think you mean the concept of showing a page of information that
> you can navigate forwards and backwards a page, or select a r
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
>> This patch doesn't seem to cope with cases where the supplied tuple has
>> the wrong number of columns, and it doesn't look like it's being
careful
>> about dropped columns either. Also, that's a mighty bizarre-looking
>> choice of cache memory
Fixed.
---
Guillaume Smet wrote:
> On 9/15/06, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> > I have completed my first pass over the release notes and Tom has made
> > some additions:
> >
> > http://momjian.postgresql
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> This patch adds a required include file to regress.c, required to get at
> InvalidTransactionId.
If that's needed, why isn't everybody else's build falling over too?
regards, tom lane
---(end of broad
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> Seems __vc_errcode was used during Visual C++ beta at some point, and is
> now declared deprecated in the system headers. This patch renames our
> use of it to __msvc_errcode, so we don't conflict anymore.
If we need this change in plpython, why not
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> This patch changes the function definition for ldap_start_tls_sA() on
> win32 by removing the WINLDAPAPI.
Applied.
regards, tom lane
---(end of broadcast)---
TIP 4: Have you se
Folks,
Could someone please provide information about how to create a correct
regression test?
Regards,
Gevik.
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> This patch fixes a couple of cases where we use strcasecmp() instead of
> pg_strcasecmp() in fe_connect.c, coming from the LDAP client pathc.
Applied. I found another instance in contrib/hstore, too. There are
also some occurrences in pgbench.c, bu
Bruce Momjian wrote:
> I have completed my first pass over the release notes and Tom has made
> some additions:
>
> http://momjian.postgresql.org/cgi-bin/pgrelease
>
> I will probably go over them again in a few hours, update them to
> current CVS, then move them into our SGML documentation
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> Here's a patch that updates the msvc build system. It contains the
> changes in Hiroshi-sans patch from about a week ago, so please apply
> this patch instead to avoid conflicts. Changes summary:
Applied, thanks.
regards, tom
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > I have completed my first pass over the release notes and Tom has made
> > some additions:
> >
> > http://momjian.postgresql.org/cgi-bin/pgrelease
> >
> > I will probably go over them again in a few hours, update them to
> > current CVS, then m
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I don't know if this is the same thing you are talking about, but Oleg
> talked to me on the conference about "partial sort", which AFAICS it's
> about the same thing you are talking about. I think Teodor submitted a
> patch to implement it, which was
Tom Lane wrote:
> [EMAIL PROTECTED] (Bruce Momjian) writes:
> > Sequences were not being shown due to the use of lowercase 's' instead
> > of 'S', and the views were not checking for table visibility with
> > regards to temporary tables and sequences.
>
> What became of my objection that the test
"Rocco Altier" <[EMAIL PROTECTED]> writes:
> With the patch attached this time...
The proposed patch to Makefile.shlib makes me gag :-( ... lying to make
about what's the purpose of a rule is seldom a good idea. Please try
as attached instead. Also, I am *really* dubious about the change to
ecpg
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> What became of my objection that the test should be on USAGE privilege
>> for the containing schema instead?
> Was this addressed?
Yes, we arrived at this:
http://archives.postgresql.org/pgsql-committers/2006-09/msg00252.php
which doe
On 9/8/06, Tom Lane <[EMAIL PROTECTED]> wrote:
It's done already ...
(Working on implementing the last changes you made in formatting in pgFouine)
Is it normal that when I set log_duration to on and log_statement to
all, I have the following output when I prepare/bind/execute a
prepared statem
"Guillaume Smet" <[EMAIL PROTECTED]> writes:
> Is it normal that when I set log_duration to on and log_statement to
> all, I have the following output when I prepare/bind/execute a
> prepared statement using the protocol:
> LOG: duration: 0.250 ms
> LOG: duration: 0.057 ms
> LOG: execute my_quer
1 - 100 of 127 matches
Mail list logo
