Re: [HACKERS] Beta time
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes: > I am checking the indexStruct->indisprimary field, but it always resolves to > false. indisunique works fine. It is a trivial change to the ADD UNIQUE > code, but it doesn't work. Viewing the system catalogs and '\d' both show > the indices as primary, but the SearchSysCache funtion believes that they > are not. Doesn't make any sense to me either. Want to post your code? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Putting timestamps in PostgreSQL log
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes: > Would it be an idea to add timestamps to the PostgreSQL error/debug/notice > log? Already done, see log_timestamp entry in postgresql.conf. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [ODBC] Odd behaviour - *possible* ODBC bug?
-Original Message- From: Jonathan Stanford > Guys, > I have some odd behaviour with VB6 & postgresql that may be a bug - I would appreciate someone else > > replicating this; or any other suggestions anyone might have. [snip] > PostgreSQL code: > CREATE TABLE tb_search ( > session_id int, > emp_id int, > rank int > ); > and some data: > insert into tb_search (session_id , emp_id, rank) values (1,101, 5); [snip several insert commands] > VB Code: [snip] > sSQL = "SELECT emp_id, sum(rank) " > sSQL = sSQL & "FROM tb_search " > sSQL = sSQL & "ON e.emp_id = s.emp_id " > sSQL = sSQL & "WHERE session_id = " & lSesh > sSQL = sSQL & " GROUP BY emp_id " > sSQL = sSQL & " ORDER BY sum(rank) DESC" > frmEmpSearch.Caption = sOrigCapt & " - retrieving results" > Set rsEmps = New ADODB.Recordset > rsEmps.CursorLocation = adUseClient 'adUseServer > rsEmps.Open sSQL, DBConn, adOpenForwardOnly, adLockReadOnly I don't think it's an ODBC driver's bug. The cause is that PostgreSQL returns NUMERIC type as sum(int). adUseClient for CursorLocation property indicates ADO to use Microsoft Cursor Service for OLE DB. Microsoft Cursor service seems to think that sum(rank) is of type int but PostgreSQL returns NUMERIC type. I don't know what should be done here. Please change sum(rank) -> sum(rank)::int and try. regards, Hiroshi Inoue ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Beta time
I spent an hour or two trying to get my ADD PRIMARY KEY patch to work but I'm beginning to think my code is suffering from bit rot. Basically, during the iteration over the indices on the table, looking for other primary indices, none are found. I am checking the indexStruct->indisprimary field, but it always resolves to false. indisunique works fine. It is a trivial change to the ADD UNIQUE code, but it doesn't work. Viewing the system catalogs and '\d' both show the indices as primary, but the SearchSysCache funtion believes that they are not. Is DefineIndex for primary indices broken or something? I have tried putting a CommandCounterIncrement() in there out of desperation, but it does nothing. Does anyone have any ideas? Might have to leave it for 7.3 I guess. Chris > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Bruce Momjian > Sent: Tuesday, 18 September 2001 12:00 AM > To: PostgreSQL-development > Subject: [HACKERS] Beta time > > > I want to mention that the number of patches submitted has dropped off > dramatically. Seems people are prepared for beta and we should start > beta as soon as we can. I think the current plan is Friday. > > Also, I will be on vacation this week. Tom will apply any patches that > look good. > > -- > Bruce Momjian| http://candle.pha.pa.us > [EMAIL PROTECTED] | (610) 853-3000 > + If your life is a hard drive, | 830 Blythe Avenue > + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 > > ---(end of broadcast)--- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html > ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] [Fwd: [Fwd: [tao-users] FW: HEADS UP: CVSup timestamp bug]]
I am still unable to update my cvs tree! What server, username, password, cvsroot and module do I need to use? Thanks, Chris > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Marc G. Fournier > Sent: Monday, 17 September 2001 8:03 PM > To: Thomas Lockhart > Cc: Hackers List > Subject: Re: [HACKERS] [Fwd: [Fwd: [tao-users] FW: HEADS UP: CVSup > timestamp bug]] > > > On Mon, 17 Sep 2001, Thomas Lockhart wrote: > > > > Got it upgraded on the cvsup.postgresql.org server ... still > have to do > > > the other servers ... > > > > I'm hopelessly confused on what servers we have, and whether that one is > > new, old, online, offline, being built, or being decommissioned. Can I > > use this machine (or virtual machine) for cvsup now? > > yes, but due to the CVSROOT move yesterday, its only as current as before > the move ... I just have to change around its pointers this morning ... > > Right now, we have: > > anoncvs.postgresql.org > == cvsup.postgresql.org > - same machine, brand new > cvs.postgresql.org > == www.postgresql.org > == mail.postgresql.org > == ssh/login server > - same machine > > rsync.postgresql.org > == ftp.postgresql.org > == primary www server > - old server, slowly being migrated between the above two > machines (rsync -> anoncvs, ftp/primary -> cvs) > > > > ---(end of broadcast)--- > TIP 4: Don't 'kill -9' the postmaster > ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Putting timestamps in PostgreSQL log
Would it be an idea to add timestamps to the PostgreSQL error/debug/notice log? Sometimes I would really like to know when an event has occurred! Chris ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] 7.2 RPMs
Lamar Owen writes: > And, while your list is a usable list of things, the lack of addressing any > of these items in no way prevents a package of 7.2 from being 'useful' for > various degrees of usefulness. ...useful in the sense that the work I'm doing becomes useful. > > * Is libpgtcl.a supposed to be in the -libs package, while libpgtcl.so is > > in -tcl? What about libpgtcl.h? Currently, the -devel package has an > > implicit dependency on Tcl, which should probably not be there. > > Huh? The libs package is intended to be the base client libraries that all > clients need. The tcl library is only needed by the tcl client. The > libpgtcl.a static lib is only needed in development, and doesn't depend upon > tcl directly. Although I have yet to see a RedHat system without tcl > installed The tcl package could, I guess, inherit libpgtcl.a from the > _devel_ package (libpgtcl.a lives there, not in libs) without problems. My interpretation of dependency is "this file cannot be made use of unless that package is installed". Hence, libpgtcl.h and libpgtcl.a have a dependency on the tcl package and therefore the postgresql-devel package has that same dependency. That is one thing, and other interpretations may be valid. The other thing is that no matter how you arrange it, libpgtcl.a and libpgtcl.so should be in the same package. I placed them in -devel for now since that is what you seemed to be intending anyway. > > * How long do we want to keep the libpq.so.2.0 symlink? > > Good question. Trond's answer is a 'long time' -- When is the next major > uprev in the library going to be? "Never" is my best guess. > Contrib, to my eyes, is both an example set as well as useful stuff. That used to be sort of true. Currently, contrib is more "useful stuff" than example. Examples are in the documentation and the tutorial directory. > However, I'm concerned about your wording 'the way it was designed to be' -- > would you mind explaining exactly what you meant (a copy of your spec file > will explain far better than any narrative could, BTW)? I mean contrib is intended to be compiled, installed, and used. > 'docs-sgml' perhaps? Maybe they want to try their hand at using an SGML > editor/publishing system to generate various docs formats? Difficult without having a real source tree available. Plus, people that want to work on documentation also have the option of getting the postgresql-docs-xxx.tar.gz source package that contains the documentation sources. > Hmmm. Any suggestions as to location and name? Might I suggest > 'kludge-to-get-around-postgresql-lack-of-upgradability' -- or is that too > inflammatory? :-) No, but it's longer than the 14 characters that POSIX allows for file names. ;-) But "upgrade" is a reasonable start. > > * What about the JDBC driver? I think the driver should be compiled in > > place by whatever JDK the build system provides. > > Got an open source JDK suggestion? One that is _standard_ for the target > distributions? There is no standard C compiler in the target distributions either... You don't need a standard JDK either. You want to build the driver to fit the JDK that the distribution provides. If the distribution doesn't provide Java support, you don't need a JDBC driver. Note that the choice of JDK is actually hidden from the build process. You just need Ant, which comes in RPM form. -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] 7.2 RPMs
On Monday 17 September 2001 05:40 pm, Trond Eivind Glomsrød wrote: > Peter Eisentraut <[EMAIL PROTECTED]> writes: > > You don't break binary compatibility by providing a shared library > > alongside a static one. > This mean backward as well... eg. perl packages for RHL 7.1 should run > on RHL 7 as well. Same for RHL 7.2, if we make such a release. Distributors' needs are very different from our needs, Peter. Maybe a potential Red Hat 8 can do such. However, the backwards compatibilty issue is some rub. Our PGDG packages, OTOH, don't have to be limited in that way. Which is one reason you may want to start there, not the Red H?at package (which is close, but not identical, to ours). -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] 7.2 RPMs
Peter Eisentraut <[EMAIL PROTECTED]> writes: > Trond Eivind Glomsrød writes: > > > > There are provisions in the source for figuring this out automatically. > > > Currently, the only "figuring" it does is to allow it on Linux. (It is my > > > understanding that it works on Linux independent of the CPU architecture. > > > In the past there have been problems with insufficient dynamic loader > > > implementations, but there is no principal design obstacle.) > > > > No. It works on IA32, but breaks elsewhere. > > Libtool seems to think otherwise. And the people who provided the > patches to libtool are the ones who should know best. Dynamic code works on those platforms. What doesn't work is dlopen() of code not compiled with -fpic (which means extensions linking with static libraries). I've not seen libtool claim otherwise, but it would be broken. Another can of worms is nsswitch inside glibc, which in some circumstances will use a dynamic module in a statically linked program. > > > But it would really be of advantage if distributors (i.e., you) supplied a > > > shared libperl by default. There are at least two high profile users > > > (PostgreSQL and Apache) running into this problem. > > > > It's not unlikely to happen for the next major series (we try hard to > > stay binary compatible within a series). > > You don't break binary compatibility by providing a shared library > alongside a static one. This mean backward as well... eg. perl packages for RHL 7.1 should run on RHL 7 as well. Same for RHL 7.2, if we make such a release. -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] 7.2 RPMs
On Monday 17 September 2001 05:44 pm, Peter Eisentraut wrote: > ...useful in the sense that the work I'm doing becomes useful. Ok. My mind is a little muddy right now, and different interpretations of wordings aren't coming easily. > The other thing is that no matter how you arrange it, libpgtcl.a and > libpgtcl.so should be in the same package. I placed them in -devel for > now since that is what you seemed to be intending anyway. Yes, that is and was my intentions; I just missed the significance of what you said. Of course, the .so and the .a need to be together in this instance (like the libpq.so/libpq.a instance as well, which was addressed earlier in the 7.1.x RPMset cycle). > > Contrib, to my eyes, is both an example set as well as useful stuff. > That used to be sort of true. Currently, contrib is more "useful stuff" > than example. Examples are in the documentation and the tutorial > directory. Then the change is valid. > > However, I'm concerned about your wording 'the way it was designed to be' > > -- would you mind explaining exactly what you meant (a copy of your spec > > file will explain far better than any narrative could, BTW)? > I mean contrib is intended to be compiled, installed, and used. Ok. I was more talking about location in the filesystem, but I get your point. > > 'docs-sgml' perhaps? Maybe they want to try their hand at using an SGML > > editor/publishing system to generate various docs formats? > Difficult without having a real source tree available. Hmmm. I've not tried to do anything with the SGML yet > > Hmmm. Any suggestions as to location and name? Might I suggest > > 'kludge-to-get-around-postgresql-lack-of-upgradability' -- or is that too > > inflammatory? :-) > No, but it's longer than the 14 characters that POSIX allows for file > names. ;-) But "upgrade" is a reasonable start. But we already had a pg_upgrade in the tarball. 'pg_migrate' perhaps? And it _is_ a kludge. > > > * What about the JDBC driver? I think the driver should be compiled in > > > place by whatever JDK the build system provides. > > > > Got an open source JDK suggestion? One that is _standard_ for the target > > distributions? > There is no standard C compiler in the target distributions either... Gcc is the de facto linux distribution standard, and one can reasonably assume that a standard C compiler is present. The same is not true of JDK's, AFAIK. > Note that the choice of JDK is actually hidden from the build process. > You just need Ant, which comes in RPM form. Hmmm. How does one get started with 'Ant' and a JDK? I personally don't use Java -- but heretofore it's been easy to get jars of the JDBC to package for people who do use Java. Is a JDBC RPM package something people are actively using? I _have_ received a few questions from people trying to use the JDBC RPM, so I think it is a useful thing to have. Somebody who knows Java: enlighten me on the portability or lack thereof of our distributed JDBC RPM's jar, please. If I can build a reasonably portable jar of our JDBC,I'm willing to try. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] MySQL development MUST immdediately cease - Due to
Quick question... Am I the only person getting rather annoyed by these messages that have started coming through recently? Once was okay, but this is getting rediculous. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 7.2 RPMs
On Monday 17 September 2001 02:21 pm, Peter Eisentraut wrote: > Trond Eivind Glomsrød writes: >> > Given that pgtksh is rather small in size I don't know if that's worth the > contortions. However, note that pgaccess is still built if you turn on Tk > but turn off %pgaccess. (There was also a plan to make pgaccess use > pgtksh, but it's not happening for 7.2.) Built!=shipped in the RPMset. Lots of things are built -- but if it's not in the %files list, it don't get packaged. > Maybe they should be named to reflect these purposes? Currently, > postgresql-dump is just another spelling of pg_dump, and rh-pgdump.sh > conveys the meaning of "Red Hat's (better/different) pg_dump". I've already suggested a name that fits the purpose. > * If the build system doesn't have a JDK, why do you need a JDBC driver? To use a compiled bytecode java application built against our JDBC with a JRE? > * There is currently no "official" source of PostgreSQL JDBC driver > binaries. So I don't know how you plan to obtain a precompiled jar > without making it yourself. Yes, we would have to build it now. However, the question still looms: _which_ JDK should be used to build it for maximum JVM/JRE compatibility for the bytecode distribution? I've asked this question before, and no consensus was reached. > Well, do you have time to work on this and do you keep the RPM input files > under version control somewhere, so I can send some incremental patches? I will have time shortly. It has been discussed in the past on two separate occassions about putting the spec file into CVS at postgresql.org, but, again, no consensus was reached and no action was taken by core to implement that. If I had to I could set up my own CVS repository -- but I haven't needed to as yet. Send a patch to me and Trond against the last PGDG release specfile. If you change the patchset, it needs to be included, as well as patches to any scripts distributed. > The preliminary spec file patch is already the same size as the spec file. ??? That's pretty big. E-mail me and Trond your changes, please. We're getting ready to go into beta, and I was getting ready to ramp up to deal with 7.2beta RPMs anyway. This just quickens the issue. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [PATCH] [LARGE] select * from cursor foo
Alex Pilosov <[EMAIL PROTECTED]> writes: > Attached patch does the above. Alex, could we have this resubmitted in "diff -c" format? Plain diff format is way too risky to apply. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Beta time
> I want to mention that the number of patches submitted has dropped off > dramatically. Seems people are prepared for beta and we should start > beta as soon as we can. I think the current plan is Friday. I'm doing a substantial amount of work on the date/time types. Not certain it will be ready for Friday. Will know more by then, of course ;) - Thomas ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] 7.2 RPMs
Trond Eivind Glomsrød writes:
> > * The {pgaccess} parameter doesn't do anything AFAICT. PgAccess is
> > installed whenever Tk support is configured (which is correct, IMO).
> > Maybe this is just a legacy item?
>
> For 7.1.3, it does make a difference
>
> %if %pgaccess
[...]
> %endif
>
> (in addition to the actual package). The 7.2 build procedure might
> differ. It's still useful to have several packages, as it under some
> circumstances it would be useful to have tk bindings but not ship
> pgaccess. E.g. if you were to ship an Asian version, this segregation
> might be useful.
Given that pgtksh is rather small in size I don't know if that's worth the
contortions. However, note that pgaccess is still built if you turn on Tk
but turn off %pgaccess. (There was also a plan to make pgaccess use
pgtksh, but it's not happening for 7.2.)
> Not only that, but you very often don't want to build it. If you have
> a static perl package, plperl can't be created. It will sort of work
> on IA32, but bomb out elsewhere. Ideally, the configure process should
> figure out this on it's own (you can't create dynamic extensions
> linking in a static lib).
There are provisions in the source for figuring this out automatically.
Currently, the only "figuring" it does is to allow it on Linux. (It is my
understanding that it works on Linux independent of the CPU architecture.
In the past there have been problems with insufficient dynamic loader
implementations, but there is no principal design obstacle.)
But it would really be of advantage if distributors (i.e., you) supplied a
shared libperl by default. There are at least two high profile users
(PostgreSQL and Apache) running into this problem.
> > * I request that rh-pgdump.sh and postgresql-dump be renamed to something
> > that conveys a semantic difference from pg_dump. Possibly, these files
> > should not be installed into /usr/bin if they're not general
> > purpose.
>
> They are programs serving specific dumping purposes.
Maybe they should be named to reflect these purposes? Currently,
postgresql-dump is just another spelling of pg_dump, and rh-pgdump.sh
conveys the meaning of "Red Hat's (better/different) pg_dump".
> > * What about the JDBC driver? I think the driver should be compiled in
> > place by whatever JDK the build system provides.
>
> Many build systems don't have a JDK, as there are no open (or even
> distributable) JDKs.
>From Red Hat I would have expected the answer "use gcj". ;-) (I don't
know how complete the class library is there, and Ant probably doesn't
support it anyway.) However, two questions arise:
* If the build system doesn't have a JDK, why do you need a JDBC driver?
* There is currently no "official" source of PostgreSQL JDBC driver
binaries. So I don't know how you plan to obtain a precompiled jar
without making it yourself.
Well, do you have time to work on this and do you keep the RPM input files
under version control somewhere, so I can send some incremental patches?
The preliminary spec file patch is already the same size as the spec file.
:-/
--
Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [HACKERS] [GENERAL] pg_dump error - LOCALIZATION PROBLEM
Peter Eisentraut <[EMAIL PROTECTED]> writes: > 2. Using strcasecmp() on strings that were parsed as keywords. See CREATE > OPERATOR, CREATE AGGREGATE, CREATE TYPE, commands/define.c. But the real point is that they were parsed as identifiers, *not* keywords, and therefore have already been through a locale-dependent case conversion. (Look at what happens in scan.l after ScanKeywordLookup fails.) Unless we can undo or short-circuit that, it won't help to apply a correct ASCII-only comparison. Possibly we should change the parser's Ident node type to carry both the raw string and the downcased-as-identifier string. The latter would serve the existing needs, the former could be used for keyword matching. > For #2, we should export parts of ScanKeywordLookup as a generic function, > perhaps "normalize_identifier", ... > For #4, we need some ASCII-only strcasecmp version. I think these are the same thing. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] 7.2 RPMs
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Trond Eivind Glomsrød writes:
>
> > > * The {pgaccess} parameter doesn't do anything AFAICT. PgAccess is
> > > installed whenever Tk support is configured (which is correct, IMO).
> > > Maybe this is just a legacy item?
> >
> > For 7.1.3, it does make a difference
> >
> > %if %pgaccess
> [...]
> > %endif
> >
> > (in addition to the actual package). The 7.2 build procedure might
> > differ. It's still useful to have several packages, as it under some
> > circumstances it would be useful to have tk bindings but not ship
> > pgaccess. E.g. if you were to ship an Asian version, this segregation
> > might be useful.
>
> Given that pgtksh is rather small in size I don't know if that's worth the
> contortions. However, note that pgaccess is still built if you turn on Tk
> but turn off %pgaccess. (There was also a plan to make pgaccess use
> pgtksh, but it's not happening for 7.2.)
It may be built, but at least you don't get the package... Personally,
I wouldn't mind separating the database core from all the other things
bundled with it (drivers, support programs). It seems a little cleaner.
> > Not only that, but you very often don't want to build it. If you have
> > a static perl package, plperl can't be created. It will sort of work
> > on IA32, but bomb out elsewhere. Ideally, the configure process should
> > figure out this on it's own (you can't create dynamic extensions
> > linking in a static lib).
>
> There are provisions in the source for figuring this out automatically.
> Currently, the only "figuring" it does is to allow it on Linux. (It is my
> understanding that it works on Linux independent of the CPU architecture.
> In the past there have been problems with insufficient dynamic loader
> implementations, but there is no principal design obstacle.)
No. It works on IA32, but breaks elsewhere.
> But it would really be of advantage if distributors (i.e., you) supplied a
> shared libperl by default. There are at least two high profile users
> (PostgreSQL and Apache) running into this problem.
It's not unlikely to happen for the next major series (we try hard to
stay binary compatible within a series).
> Maybe they should be named to reflect these purposes? Currently,
> postgresql-dump is just another spelling of pg_dump, and rh-pgdump.sh
> conveys the meaning of "Red Hat's (better/different) pg_dump".
It was basically "doh, the existing dump script is very broken and we
freeze very soon" a release or two ago. I think Lamar was the one who
discoverd it and I the one who wrote it rather quickly.
> > > * What about the JDBC driver? I think the driver should be compiled in
> > > place by whatever JDK the build system provides.
> >
> > Many build systems don't have a JDK, as there are no open (or even
> > distributable) JDKs.
>
> From Red Hat I would have expected the answer "use gcj". ;-) (I don't
> know how complete the class library is there, and Ant probably doesn't
> support it anyway.) However, two questions arise:
gcj is nice, but far from complete. It's also Java 1.1 without AWT,
AFAIR, and most interesting stuff use 1.2 and up now.
> * If the build system doesn't have a JDK, why do you need a JDBC
> driver?
That you can use with gcj :). The main reason it's useful is that
other can install their own JDK, typically when running servlets or
other server based Java apps.
> Well, do you have time to work on this and do you keep the RPM input files
> under version control somewhere, so I can send some incremental
> patches?
If you send it, I can have a first look. As for time, that's something
other people have. And when I have it, I don't have anything to use it
for either (maxed out with 5 weeks unused vacation now, but have no
idea what to use most of it for)
--
Trond Eivind Glomsrød
Red Hat, Inc.
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [GENERAL] pg_dump error - LOCALIZATION PROBLEM
Tom Lane writes: > I think our problems are worse than that: once the identifier has been > through a locale-dependent case conversion we really have a problem > matching it to an ASCII string. The only real solution may be to > require *all* keywords to be matched in the lexer, and forbid strcmp() > matching in later phases entirely. There are several classes of strcasecmp() misuse: 1. Using strcasecmp() on strings that are guaranteed to be lower case, because the parser has assigned to the variable one of a finite set of literal strings. See CREATE SEQUENCE, commands/sequence.c for example. 2. Using strcasecmp() on strings that were parsed as keywords. See CREATE OPERATOR, CREATE AGGREGATE, CREATE TYPE, commands/define.c. 3. Using strcasecmp() on the values of GUC variables. 4. Using strcasecmp() for parsing configuration files or other things with separate syntax rules. See libpq/hba.c for reading the recode table. For #1, strcasecmp is just a waste. For #2, we should export parts of ScanKeywordLookup as a generic function, perhaps "normalize_identifier", and then we can replace strcasecmp(var, "expected_value") with strcmp(normalize_identifier(var), "expected_value") For #3, it's not quite clear, because the string value could have been created by an identifier or a string constant, so it's either #2 or #4. For #4, we need some ASCII-only strcasecmp version. -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] 7.2 RPMs
On Sunday 16 September 2001 11:22 pm, Peter Eisentraut wrote:
> I just took a dreadful look at the RPMs. I've managed to build something
> that resembles a 7.2 package, but there are a number of things that we
> should talk about so this ends up being useful.
First, thanks for taking a look. However,I don't think 'dreadful' is a
really appropriate word here. But I'll let it slide. RPM packaging in
general can be a dreadful experience -- and that's what I'm going to assume
that you meant.
And, while your list is a usable list of things, the lack of addressing any
of these items in no way prevents a package of 7.2 from being 'useful' for
various degrees of usefulness.
> * The {pgaccess} parameter doesn't do anything AFAICT. PgAccess is
> installed whenever Tk support is configured (which is correct, IMO).
> Maybe this is just a legacy item?
As I've not yet had the time to build any 7.2 RPMsets, I'll have to look. It
may very well be legacy if 7.2's makefiles do such a decision as to install
pgaccess and where to install it.
But, pgaccess!=tk_client_support and might not even be desired by a tk client
user.
> * I removed the {plperl} parameter, because PL/Perl now builds by default
> on Linux. Should plperl continue to stay its own package? I'd say yes,
> because you don't need in on every client.
PL/perl requires a dynamic load libperl.so -- which Red Hat doesn't ship. If
configure can test for a dynamic libperl (which is being done in the makefile
as of 7.1.3), then that's where that decision ought to be made. However,
Karl DeBisschop can shed much light on this particular subject, and his
opinion should be weighed, as he knowsof some interesting situations.
As to it remaining a separate package -- absolutely. PL/perl is a
server-side package, while the perl client might be installed without a
server on its system. Don't want to force the server on a perl client
machine.
> * Related to previous, the tcl package currently includes client and
> server components. I'd say this is more useful as two separate packages.
> * Similar issues with PL/Python
I agree, and had planned on doing just this.
> * Is libpgtcl.a supposed to be in the -libs package, while libpgtcl.so is
> in -tcl? What about libpgtcl.h? Currently, the -devel package has an
> implicit dependency on Tcl, which should probably not be there.
Huh? The libs package is intended to be the base client libraries that all
clients need. The tcl library is only needed by the tcl client. The
libpgtcl.a static lib is only needed in development, and doesn't depend upon
tcl directly. Although I have yet to see a RedHat system without tcl
installed The tcl package could, I guess, inherit libpgtcl.a from the
_devel_ package (libpgtcl.a lives there, not in libs) without problems.
> * How long do we want to keep the libpq.so.2.0 symlink?
Good question. Trond's answer is a 'long time' -- When is the next major
uprev in the library going to be? This needs to be researched -- the
question that needs answering here is 'how many third-party packages (such as
the php postgresql interface; the DBI postgresql interface, etc) are going to
be broken by this?'
> * I fail to understand the motivation behind the way the -contrib package
> is done. You seem to be installing the source code. I scrapped that and
> installed the binaries the way it was designed to be.
Contrib, to my eyes, is both an example set as well as useful stuff. As 7.1
was the first setof RPM's with contrib compiled at all (previously, the
entire contrib tree was packaged as source code for documentation!), having
the source as well enables examples -- however, I understand both sides of
that.
However, I'm concerned about your wording 'the way it was designed to be' --
would you mind explaining exactly what you meant (a copy of your spec file
will explain far better than any narrative could, BTW)?
> * The -docs package is misleading. Maybe it should be called -docs-devel
> or something. However, I'm having a hard time understanding how people
> can make use of this.
'docs-sgml' perhaps? Maybe they want to try their hand at using an SGML
editor/publishing system to generate various docs formats? It was previously
packaged as part of the main package and I split it out.
> * I request that rh-pgdump.sh and postgresql-dump be renamed to something
> that conveys a semantic difference from pg_dump. Possibly, these files
> should not be installed into /usr/bin if they're not general purpose.
Hmmm. Any suggestions as to location and name? Might I suggest
'kludge-to-get-around-postgresql-lack-of-upgradability' -- or is that too
inflammatory? :-) However, I tend to agree -- /usr/bin might not be the best
location for these scripts.
> * What about the JDBC driver? I think the driver should be compiled in
> place by whatever JDK the build system provides.
Got an open source JDK suggestion? One that is _standard_ for the tar
Re: [HACKERS] Hot spare PSQL server
Thus spake Turbo Fredriksson > Justin> http://pgreplicator.sourceforge.net > > Unfortunatly this seems to be asynchronous replication (you manually > have to initiate the syncronization)... And it also uses the GNU license. -- D'Arcy J.M. Cain| Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Beta time
I want to mention that the number of patches submitted has dropped off dramatically. Seems people are prepared for beta and we should start beta as soon as we can. I think the current plan is Friday. Also, I will be on vacation this week. Tom will apply any patches that look good. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Hot spare PSQL server
> > > Unfortunatly this seems to be asynchronous replication (you manually > have to initiate the syncronization)... > > I'd like to have synchronous replication... There is a synchronous replication project here... http://www.greatbridge.org/project/pgreplication/projdisplay.php We currently have a "working model" based on PostgreSQL-6.4.2, and are working on implementing the ideas in PostgreSQL-7.1.3. Darren ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] NewYork Bombing: SQL server bomb proof!!
This is probably the worst post I have seen in a newsgroup ever. Using this tragedy so promote a product is disgusting. You are not doing the product you are promoting a favor with this. I will not comment on the technical content of this post. Serge ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] CD-RW Scheduled Database Backup...
Hi All, (sorry for the .questions/.hackers crosspost) I'm a relatively new Linux / PostgreSQL user, and I've been scouring for a few weeks now to find an answer to my problem -- bugging newsgroups with my newbie questions is my last resort. I have a Postgres DB that I wish to have automagically pg_dumped to a dated text file and burned to a Multi-Session CD. These are two seperate issues (I can't get either to work properly) that I need help with -- the scripted database dump and then the sequential cd burn. Here is the command I tried using: pg_dump -C -d myDb > myDbSept.out The problem is that I need a login / password to execute this command, and it is asking for a password at an echo prompt! I tried using the PGUSER / PGPASSWORD variables, but they didn't work (or, at least I don't know how to use them properly) As for the cd-burning component, that's a whole other mess I'm going to have to bug the linux.cd people about. Could someone please nudge me in the right direction, or if they've already done something like this (with the burn), perhaps post up a sample of their script? Thanks ever so much, Rums. REMOVErumsAThomeDOTcom ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] triggers procedures listing URGENT
Have a look into the system tables pg_proc pg_trigger Have a look into the documentation, refer to System Catalogs Within psql you get System Catalogs listed by \dS specific information about a table by i. e. \d pg_proc Regards, Christoph ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] NewYork Bombing: SQL server bomb proof!!
Not to mention that PostgreSQL is WAY ahead on technology. peace_flower wrote: > I can bet that open-source code SQL server like PostgreSQL is bomb-proof > and even in case of nuclear war world-wide, > the source code of PostgreSQL will be very safe at some point on the > planet and can easily be distributed and multiplied rapidly. > > The reason being internet is nuclear-bomb proof storage center and > PostgreSQL source code is stored on internet.. > > This is a point why large enterprises should consider PostgreSQL. > > Internet SQL server like PostgreSQL will gain rapid momentum > world-wide ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] BindColumn and Bulk Copy
I suppose that a user group would be more appropriate for this question, but I think there is some potential for further development here. I want to port a program that makes extensive use of BindColumn/DefineColumn semantics of ODBC, as well as bulk copy operations. My problem is that the current ODBC driver doesn't support bulk copy and libpq doesn't support Bind/Define. What should I be using, and will I have to develop this functionality for one of these interfaces? --Kevin ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] MySQL development MUST immdediately cease - Due to GlobalEconomic condition..
This is a immediate order to COMPLETELY STOP and CEASE all development of MySQL database server. This is due to rapid changes in the Global Economic conditions.. You do not have time to deal with one powerful SQL server like PostgreSQL, where do you have time to deal with two types of SQL servers. Question is why have two?? There is no time to deal with two open source SQL servers. After doing research, it is recommended that you stick with just PostgreSQL. With huge amount of efforts MySQL can be brought closer to PostgreSQL level (and perhaps it may NEVER be possible to bring MySQL to the level of technology of PostgreSQL). Even if it is done it will be a waste of time.. The WORLD economy started taking nose dive for the last 2 years. Last year a mild global economic recession started which forced thousands of companies world-wide closing down. Last year millions of dot-com went bust. It is predicted that there is a impending "World-War-III" like situation is developing in the middle-east and Afghanistan which may have significant effect in Asian and European countries. But that may NOT have lot of economic effects on North/South American countries like Brazil, USA, Canada, Mexico.. Nevertheless, overall economy of the globe will get the impact. And, hence drop off the MySQL now and migrate all your data to PostgreSQL.. By the way, PostgreSQL runs on all platforms - All unixes, linux, Apple Macintosh and MS Windows 98/NT/2000 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] triggers procedures listing URGENT
Hi Friends,I'm just a beginner, partaking in a project.Is there any way to list or edit the user-definedprocedures, functions and triggers?I have already loaded them into the postgres databaseand trying to edit and list it.thanks,francis
[HACKERS] NewYork Bombing: SQL server bomb proof!!
I can bet that open-source code SQL server like PostgreSQL is bomb-proof and even in case of nuclear war world-wide, the source code of PostgreSQL will be very safe at some point on the planet and can easily be distributed and multiplied rapidly. The reason being internet is nuclear-bomb proof storage center and PostgreSQL source code is stored on internet.. This is a point why large enterprises should consider PostgreSQL. Internet SQL server like PostgreSQL will gain rapid momentum world-wide ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Hot spare PSQL server
> "Justin" == Justin Clift <[EMAIL PROTECTED]> writes: Justin> Hi, There's also "PostgreSQL Replicator", which is at : Justin> http://pgreplicator.sourceforge.net Unfortunatly this seems to be asynchronous replication (you manually have to initiate the syncronization)... I'd like to have synchronous replication... -- Turbo __ _ Debian GNU Unix _IS_ user friendly - it's just ^/ /(_)_ __ _ ___ __ selective about who its friends are / / | | '_ \| | | \ \/ / Debian Certified Linux Developer _ /// / /__| | | | | |_| |> < Turbo Fredriksson [EMAIL PROTECTED] \\\/ \/_|_| |_|\__,_/_/\_\ Stockholm/Sweden explosion Rule Psix spy Ortega Panama arrangements PLO genetic Uzi Treasury Peking Waco, Texas quiche jihad security [See http://www.aclu.org/echelonwatch/index.html for more about this] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [Fwd: [Fwd: [tao-users] FW: HEADS UP: CVSup timestamp bug]]
On Mon, 17 Sep 2001, Thomas Lockhart wrote: > > Got it upgraded on the cvsup.postgresql.org server ... still have to do > > the other servers ... > > I'm hopelessly confused on what servers we have, and whether that one is > new, old, online, offline, being built, or being decommissioned. Can I > use this machine (or virtual machine) for cvsup now? yes, but due to the CVSROOT move yesterday, its only as current as before the move ... I just have to change around its pointers this morning ... Right now, we have: anoncvs.postgresql.org == cvsup.postgresql.org - same machine, brand new cvs.postgresql.org == www.postgresql.org == mail.postgresql.org == ssh/login server - same machine rsync.postgresql.org == ftp.postgresql.org == primary www server - old server, slowly being migrated between the above two machines (rsync -> anoncvs, ftp/primary -> cvs) ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Hot spare PSQL server
I'd like to have a hot standby server for our main PSQL... I've seen that there are a number of products that might do the trick, Mission Critical Linux (and their Convolu Cluster/IBM FC SAN), Usogres and DBBalancer. All seem (at least 'on paper') to solve this problem. The Convolu seem a little expensive (and won't provide any loadbalancing which might be needed later), usogres seems promising, but like vise don't support load balancing. DBBalancer is the most promising, but the coders feel the different ports for read/write is a little ... annoying :) Is there any other products I missed? -- Turbo __ _ Debian GNU Unix _IS_ user friendly - it's just ^/ /(_)_ __ _ ___ __ selective about who its friends are / / | | '_ \| | | \ \/ / Debian Certified Linux Developer _ /// / /__| | | | | |_| |> < Turbo Fredriksson [EMAIL PROTECTED] \\\/ \/_|_| |_|\__,_/_/\_\ Stockholm/Sweden genetic munitions radar security Saddam Hussein 767 spy Soviet attack killed SEAL Team 6 president smuggle NORAD Iran [See http://www.aclu.org/echelonwatch/index.html for more about this] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] lo_creat() bug
Hi all,
I was just looking through libpq large object code an noticed what seemed
to be a bug. The function lo_create() is declared as Oid yet it contains
the following code:
if (conn->lobjfuncs == (PGlobjfuncs *) NULL)
{
if (lo_initialize(conn) < 0)
return -1;
}
If lo_initialize returns < 0, you have some pretty serious problems - out
of memory, conn is invalid, etc. However, casting -1 to Oid returns what
seems to be a valid Oid. Shouldn't it return InvalidOid?
Gavin
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
