>> http://www.joeconway.com/lxr.pgsql/
>>
>> It just needs apache, perl, glimpse, agrep, and a small amount of
>> configuration (and of course a fresh copy of cvs tip).
I've long used glimpse + an emacs macro for searching the sources.
LXR seems to add little to the glimpse engine except for an
I'd love such a service...
Makes it a lot easier for me to figure out what the heck all the functions
and types are...
Chris
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Joe Conway
> Sent: Tuesday, 26 March 2002 2:32 PM
> To: pgsql-hackers
> Su
Has anyone ever considered setting up LXR to cross-reference pgsql
source on developer.postgresql.org or maybe techdocs.postgresql.org? I
have seen it used in a couple of projects (originally written for the
Linux kernel; lxr.php.net is another user), and it seems pretty useful.
I set one up i
Sorry for the package, but the following patch need
to be applied to get the new verion compiled on SCO Openserver 5.0.5 and
Unixware 7.1.1
pgsql-7.2.1.diff
Description: Binary data
---(end of broadcast)---
TIP 5: Have you checked our extensi
On Tue, 26 Mar 2002, Christopher Kings-Lynne wrote:
> > Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> > > I have throught of at least two problems with changing nullability. The
> > > first is primary keys. I have to prevent people setting a
> > column involved
> > > in a PK to null, r
Other than the documentation issues, I confirm the tarball looks good
from here.
regards, tom lane
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Bruce Momjian wrote:
>
> Why? Why shouldn't the documentation match the release number?
Shouldn't "major version" still be 7.2, and version be "7.2.1".
i.e. "7.2.1" is a minor release/update/subversion of "7.2"?
Regards and best wishes,
Justin Clift
>
> --
> Bruce Momjian
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> But neither explanation warrants setting "majorversion" to 7.2.1.
>
> > Why? Why shouldn't the documentation match the release number?
>
> Did you look at how majorversion is used?
>
> Setting it to 7.2.1 is *clearly* wrong.
Oh,
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> But neither explanation warrants setting "majorversion" to 7.2.1.
> Why? Why shouldn't the documentation match the release number?
Did you look at how majorversion is used?
Setting it to 7.2.1 is *clearly* wrong.
regards, to
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > > Is this right, or should "majorversion" still be 7.2? Right offhand
> > > the latter seems correct ...
> >
> > I wasn't sure what to do here. I figured if the docs were regenerated,
> > it should say 7.2.1, and if they aren't, then they wi
Bruce Momjian writes:
> > Is this right, or should "majorversion" still be 7.2? Right offhand
> > the latter seems correct ...
>
> I wasn't sure what to do here. I figured if the docs were regenerated,
> it should say 7.2.1, and if they aren't, then they will stay as 7.2.
But neither explanati
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Marc G. Fournier writes:
> >> Try her out and let me know if there are any problems ... the build looks
> >> clean, sizes all look right ...
>
> > ... but the contained documentation is for 7.3.
>
> On the subject of contained do
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Marc G. Fournier writes:
>> Try her out and let me know if there are any problems ... the build looks
>> clean, sizes all look right ...
> ... but the contained documentation is for 7.3.
On the subject of contained documentation, I notice
*** postg
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> What about temporary tables - is there any reason they shouldn't be able to
> modify a temporary table?
I don't see one.
> What about indices? Will twiddling the nullability break indices on a table
> in any way?
No, not as long as you ar
Marc G. Fournier writes:
> Try her out and let me know if there are any problems ... the build looks
> clean, sizes all look right ...
... but the contained documentation is for 7.3.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)
> Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> > I have throught of at least two problems with changing nullability. The
> > first is primary keys. I have to prevent people setting a
> column involved
> > in a PK to null, right?
>
> Probably so.
What about temporary tables - is there a
Try her out and let me know if there are any problems ... the build looks
clean, sizes all look right ... if no visible probs, will announce in the
mroning ...
On Mon, 25 Mar 2002, Marc G. Fournier wrote:
>
> Just before anyone asks where it is ... I'm just rolling v7.2.1 up right
> now and wil
Just before anyone asks where it is ... I'm just rolling v7.2.1 up right
now and will let everyone know once its ready for a download ... I'll do
up an announce in the morning unless anyone finds a flaw in it ...
---(end of broadcast)---
TIP 5:
Please check current CVS or snapshot. I believe this is fixed.
---
Ulrich Neumann wrote:
> Hello everybody,
>
> i've found a little bug in pqsignal.h. Attached is the patch.
> (AuthBlockSig wasn't defined in one case).
>
Hello everybody,
i've found a little bug in pqsignal.h. Attached is the patch.
(AuthBlockSig wasn't defined in one case).
This problem is not specific to a special platform, it may target several
platfroms.
best regards
Ulrich Neumann
Novell Worldwide Developer Support
begin 666 pqsignal.patc
Hello everybody,
If possible please add the following patch to better support NetWare.
best regards
Ulrich Neumann
Novell Worldwide Developer Support
begin 666 xlog.patch
M+2TM(%QP9W-Q;#&-E<'0@9F]R('1H92!T2!P
M87)A;F]I9"X-"B`)("HO#0HM(VEF;F1E9B!?7T)%3U-?7PT**R-I9B`A9&5F
M:6YE9"A?7T)%3U-?7RD@)B
Tom Lane wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > Currently, PostgreSQL allows this -- when the session ends and the temp
> > table is dropped, an subsequent queries on the view fail. Is this the
> > optimal behavior?
>
> Well, I think it's better than refusing views on temp tables, a
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> If LOCALE_NAME_BUFLEN changes size between writing and reading the
> control file, the CRC *could* still be calculated correctly.
There might be some value to storing sizeof(ControlFileData) explicitly,
so that that CRC calculation could be made. But
> > OK, I'll add NAMEDATALEN, FUNC_MAX_ARGS, and LOCALE_NAME_BUFLEN. Any
> > more?
> No, you're missing my point: there is zero value in adding
> LOCALE_NAME_BUFLEN as an explicit field in ControlFileData.
> The entire physical layout of ControlFileData has to be implicit in
> PG_CONTROL_VERSION,
On Mon, 25 Mar 2002, Joel Burton wrote:
> (posted last week to pgsql-general; no responses there, so I'm seeing if
> anyone here can contribute. Thanks!)
>
>
> I'm working on a site hosted in a BSD Jail; they have MySQL installed but,
> of course, I'd rather use PostgreSQL.
>
> It installs fine b
> Your assumption is correct. All I need is what you described:
> #ifdef __CYGWIN__
> to
> #if defined(__CYGWIN__) || defined(N_PLAT_NLM)
Great. I'll include that in a set of patches I'm working on.
> Sorry that the patchfile didn't include the context. I will make sure that this
> doesn't happe
(posted last week to pgsql-general; no responses there, so I'm seeing if
anyone here can contribute. Thanks!)
I'm working on a site hosted in a BSD Jail; they have MySQL installed but,
of course, I'd rather use PostgreSQL.
It installs fine but can't initdb; get the following:
Fixing permission
[EMAIL PROTECTED] ("Luis Alberto Amigo Navarro") writes:
> we're running on sgi powerchallenge, 8 r1 4-way smp, and we're
> getting bad performance from postgres, throughput increases from 1
> to 5 streams, but from 5 and above there is no further increase,
> performance analysis show hig
28 matches
Mail list logo
