Re: [HACKERS] Release changes
On Mon, 4 Aug 2003, Christopher Kings-Lynne wrote: Oleg - have you followed the latest discussion on why tsearch2 isn't compilable on FreeBSD? Nop, Teodor's development machine is FreeBSD and he has no problem :) We'll look Chris - Original Message - From: Oleg Bartunov [EMAIL PROTECTED] To: Bruce Momjian [EMAIL PROTECTED] Cc: PostgreSQL-development [EMAIL PROTECTED] Sent: Monday, August 04, 2003 1:28 PM Subject: Re: [HACKERS] Release changes Bruce, you forgot new contrib/tsearch2 module - full text extension (Oleg,Teodor) Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] statement level trigger causes pltcl,
Joe Conway said: Hmm, same problem. Looks like PL/pgSQL does the right thing, but plpython will crash also. I don't think plperl supports triggers. Right -- I only had time to implement support for statement-level triggers in the backend itself and in PL/PgSQL. Thanks for taking the time to update PL/TCL -- you're welcome to go ahead and fix PL/Python as well, if you're so inclined. -Neil ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Release changes
Bruce Momjian wrote: Here are the changes for 7.4. I am looking for any improvements. This will be adjusted as we move through beta. --- Add FOR EACH STATEMENT statement-level triggers (Neil Conway) AFAICS the current implementation still doesn't have a way to access the affected rowset, so it'a pretty much like a SELECT without a WHERE. This restricts the usability of statement-level triggers to very limited cases. IMHO it's not a good idea to announce an incompletely implemented feature. Regards, Andreas ---(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
[HACKERS] truncate all?
Hi! Would it be possible to implement a truncate all that purges all tuples from *all* tables, without taking account any rules or triggers, but leaving all table structures and rules, triggers, functions, etc intact (sequences do not need to reinitialized)? As far as I understand, the no truncate if table is referenced change was introduced to ensure database integrity. However, if the referencing table is truncated, too, there should be no problem as far as foreign keys are concerned, correct? The rationale behind this suggestion is that in our project we need a *quick* way to get rid of all the tuples in all tables in order to accelerate the reinitialization of the database for our unit tests. This needs to be done fairly often, and so the quicker the unit tests run, the easier it will be to include many unit tests in our project, thus ensuring that we can develop efficiently and safely in postgresql. If you know of some other *quick* way to truncate all tables, please let us know. BTW: Starting and later rolling back a transaction will not work, as we also need to check whether the correct exceptions are raised. This all option to truncate would really help to accelerate unit tests (besides of making them more readable) and should be fairly easy to implement, but I am not sure how to change the relevant postgresql code. I would be glad if someone could suggest some easy way to do it, and what needs to be observed to implement such an extension of postgresql. I also hope that such an extension could be included in future version of postgresql, but for now some easy patch to the latest version would do as well. Thanks for your time, Andi. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] truncate all?
On 4 Aug 2003 at 11:25, Andreas wrote: Would it be possible to implement a truncate all that purges all tuples from *all* tables, without taking account any rules or triggers, but leaving all table structures and rules, triggers, functions, etc intact (sequences do not need to reinitialized)? As far as I understand, the no truncate if table is referenced change was introduced to ensure database integrity. However, if the referencing table is truncated, too, there should be no problem as far as foreign keys are concerned, correct? The rationale behind this suggestion is that in our project we need a *quick* way to get rid of all the tuples in all tables in order to accelerate the reinitialization of the database for our unit tests. This needs to be done fairly often, and so the quicker the unit tests run, the easier it will be to include many unit tests in our project, thus ensuring that we can develop efficiently and safely in postgresql. If you know of some other *quick* way to truncate all tables, please let us know. BTW: Starting and later rolling back a transaction will not work, as As a workaround, I would dump the schema to a file using pg_dump, drop the database and recreate it from schema. Will that do for you? Unfortunately that is not transaction safe and any clients connected at that time needs to disconnect first. Hopefully you can do that in the test environment. HTH Bye Shridhar -- Bubble Memory, n.: A derogatory term, usually referring to a person's intelligence. See also vacuum tube. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] 7.4 COPY BINARY Format Change
Tom Lane writes: Lee Kindness [EMAIL PROTECTED] writes: Well in that case the docs need attention. They describe the envelope surrounding the tuples, but no mention is made of the format they are in. It is reasonable to assume that this format was the native binary format, as in earlier releases. Yeah, there should be some mention of that in the COPY ref page I guess --- it's mentioned in the frontend protocol chapter, but not under COPY. In my defense I'd point out that the contents of individual fields have never been documented under COPY. True, the docs have always skipped the specifics for the tuples. But now that the format has evolved beyond a simple dump of the bytes the tuple format does need discussing. What do I need to do to make this code work with 7.4? Is there any docs describing the binary format for each of the datatypes or do I need to reverse-engineer a dump file or look in the source? ATM, I'd recommend looking in the sources to see what the datatype send/receive routines do. I have been thinking about documenting the binary formats during beta, but am unsure where to put the info. We never documented the internal formats before either, so there's no obvious place. Perhaps the documentation of the binary format should be taken out of the COPY docs and moved into the client interfaces documentation? the COPY docs would of course reference the new location. Just now the tuples could be documented simply by referring the reader to the relevant functions in the relevant source files. After all the source is the best documentation for this sort of thing. Are the routines in libpq/pqformat.c intended to be used by client applications to read/write the binary COPY files? They are not designed to be used outside the backend environment, although possibly some enterprising person could adapt them. I am not sure there's any value in it though. Copying the backend code helps only if what you want to get out of the transmission is the same as the backend's internal format, which for anything more complex than int/float/text seems a bit dubious. I think there is a lot of use for a binary COPY file API within libpq - routines to open a file, write/read a header and write/read common datatypes. This would remove the need for most people using the binary version of COPY to even know the file format. This would also isolate people who use this API from any future changes. Would libpq or contrib be the best place for this? Would you agree this is a good idea for 7.4? I've already got something along these lines: extern FILE *lofsdb_Bulk_Open(char **filename); extern void lofsdb_Bulk_Close(FILE *f, char *filename); extern void lofsdb_Bulk_Write_NCols(FILE *f, short ncols); extern void lofsdb_Bulk_Write(FILE *f, void *data, size_t sz, size_t count, short ind); extern void lofsdb_Bulk_WriteText(FILE *f, char *data, short ind); extern void lofsdb_Bulk_WriteBytea(FILE *f, char *data, size_t len, short ind); extern void lofsdb_Bulk_WriteTime(FILE *f, double t, short ind); extern void lofsdb_Bulk_WriteTimeNow(FILE *f); which could form the basis of a contrib module to handle writing out 7.1 through to 7.4 format files. Naturally lofsdb_Bulk_Write needs to go and be replaced by specific functions. Well as pointed out in my earlier message nothing has changed which requires the format to change - there is no real reason it's now PGCOPY and the integer layout field has disappeared. Given that the interpretation of the field contents has changed drastically, I thought it better to make an obvious incompatible change. We could perhaps have kept the skeleton the same, but to what end? An app trying to read or write the file as if it were pre-7.4 data would fail miserably anyway. Yeah, but someone (actually you!) went to the effort of making the 7.1 format extensible and documenting it as such... It could have handled the changes. I am still willing to make a patch which does this (to aid those writing COPY format files) and to fully support the reading of the old format tuples. However i'm not going to waste both our time if this patch is not going to be positively considered... My vote will be to reject it because of the security problem. In which case I think my time would be better spent looking at the API described above. I can't think of much use of byte swapping when 99% of the use of COPY BINARY FROM is to improve performance over using INSERT. Both the reader and writer will be using the same binary integer/float/etc formats! You must think that the universe consists exclusively of Intel hardware. In my view, standardizing on a machine-independent binary format will greatly *expand* the usefulness of COPY BINARY, since the files will not be tied to a single architecture. Well my testing (or lack of) of the earlier patch would seem to indicate it was done on
Re: [HACKERS] [ADMIN] concat_ws
=?ISO-8859-1?Q?Dennis_Bj=F6rklund?= [EMAIL PROTECTED] writes: On Sun, 3 Aug 2003, Tom Lane wrote: I added code to inline_function to stop inlining if a parameter expression to be substituted multiple times has cost greater than 10*cpu_operator_cost (which roughly means that it contains more than 10 operators or functions). When is this inlining taking place and what is the logic? I just want to make sure that there is no code in pg that will unfold forever, say for example for a recursive fac() function. From the above it sounds like that might be a problem. That's already dealt with. See inline_function() in src/backend/optimizer/util/clauses.c. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] DROP TYPE/DROP DOMAIN
Christopher Kings-Lynne [EMAIL PROTECTED] writes: I notice you can use the 'DROP TYPE' syntax to drop a domain. Should that be allowed? Why not? A domain *is* a type, by any reasonable test. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] 7.4 COPY BINARY Format Change
Lee Kindness [EMAIL PROTECTED] writes: However, is COPY BINARY meant/designed to be used as transfer or backup mechanism? I think you're overlooking a key consideration: COPY BINARY is not an isolated feature anymore. By design it uses the same data representations as are used for binary query parameters and results in the rest of the 7.4 FE/BE protocol. I could see some value in providing byte-swapping routines in libpq to convert between local and network representations for integers and floats. The underlying facilities (ntohl etc) are readily available, of course, but it's a small matter that is easy to get wrong. I'm not sure it's worth packaging up COPY BINARY logic per se. I think you'd end up with an API not materially simpler than dealing with the format directly. And I'm unconvinced it'd actually be used widely, whereas I do expect binary transfer of individual values to be common. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] truncate all?
On Mon, 2003-08-04 at 05:40, Shridhar Daithankar wrote:
On 4 Aug 2003 at 11:25, Andreas wrote:
Would it be possible to implement a truncate all that purges all tuples
from *all* tables, without taking account any rules or triggers, but
leaving all table structures and rules, triggers, functions, etc intact
(sequences do not need to reinitialized)?
As far as I understand, the no truncate if table is referenced change was
introduced to ensure database integrity. However, if the referencing table
is truncated, too, there should be no problem as far as foreign keys are
concerned, correct?
The rationale behind this suggestion is that in our project we need a
*quick* way to get rid of all the tuples in all tables in order to
accelerate the reinitialization of the database for our unit tests. This
needs to be done fairly often, and so the quicker the unit tests run, the
easier it will be to include many unit tests in our project, thus ensuring
that we can develop efficiently and safely in postgresql.
If you know of some other *quick* way to truncate all tables, please let us
know. BTW: Starting and later rolling back a transaction will not work, as
As a workaround, I would dump the schema to a file using pg_dump, drop the
database and recreate it from schema.
Will that do for you? Unfortunately that is not transaction safe and any
clients connected at that time needs to disconnect first. Hopefully you can do
that in the test environment.
Truncate isn't transaction safe either, so that shouldn't be a problem.
Proper syntax for his feature would seem like:
truncate table [cascade|restrict] ?
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [HACKERS] DROP TYPE/DROP DOMAIN
Tom Lane writes: Christopher Kings-Lynne [EMAIL PROTECTED] writes: I notice you can use the 'DROP TYPE' syntax to drop a domain. Should that be allowed? Why not? A domain *is* a type, by any reasonable test. According to that logic, a view is a table, but we still require DROP VIEW to drop a view. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] Thread-safe configuration option appears to misfunction
Is it intended that libpq is always compiled with the so-called thread-safe compiler option, regardless of whether I used --enable-thread-thing? -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] DROP TYPE/DROP DOMAIN
Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane writes: Why not? A domain *is* a type, by any reasonable test. According to that logic, a view is a table, but we still require DROP VIEW to drop a view. No, a view is not a table. Try putting an index or trigger on it. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Release changes
Oleg Bartunov [EMAIL PROTECTED] writes: On Mon, 4 Aug 2003, Christopher Kings-Lynne wrote: Oleg - have you followed the latest discussion on why tsearch2 isn't compilable on FreeBSD? Nop, Teodor's development machine is FreeBSD and he has no problem :) I think the problem may only occur when using --enable-depend (although building outside the source tree might also show up some problems). Peter is of the opinion that you need a full-fledged Makefile in each subdirectory --- you can't get away with having the upper Makefile build stuff in the lower directories. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] truncate all?
Truncate isn't transaction safe either, so that shouldn't be a problem. Actually, it is in 7.4 Proper syntax for his feature would seem like: truncate table [cascade|restrict] ? Agreed. signature.asc Description: This is a digitally signed message part
Re: [HACKERS] DROP TYPE/DROP DOMAIN
Tom Lane writes: Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane writes: Why not? A domain *is* a type, by any reasonable test. According to that logic, a view is a table, but we still require DROP VIEW to drop a view. No, a view is not a table. Try putting an index or trigger on it. According to that logic, a domain is not a type. Try putting a check constraint on it. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] truncate all?
On Mon, 2003-08-04 at 10:28, Rod Taylor wrote:
Truncate isn't transaction safe either, so that shouldn't be a
problem.
Actually, it is in 7.4
yeah i know, but I assumed he wasn't doing his production unit testing
against 7.4. Course if he is all the better I suppose... :-)
Proper syntax for his feature would seem like:
truncate table [cascade|restrict] ?
Agreed.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
[HACKERS] postmaster core [ 2 ]
Hi all, last week ( 27/7/2003 ) I did a post with subj: postmaster core ( finally I have it ), at that time I was supspecting that the core was caused by a select on a view ( the view is always the same that cause the core ) that was running together with a vacuum; Tom Lane told me that is really strange that vacuum could cause a core of a process doing a select on a view; so that day I removed this normal, I think, race ( vacuum + select on that view at the same time ) and after 7 days I still don't have a new core ( normally I already had it ). My conclusion ( is true that I never seen the vacuum code ) is that vacuum do something strange. Is also true that I never seen some one have this problem but may be because the core is not created if you don't esplicit set ulimit. My DB is really stressed I have an average of 70 connections and an average of 1600 commit for each minute. Regards Gaetano Mendola BTW I had another strange situation in the past: a reindex on a table was the cause of having a primary key duplicated. I removed ( now are months ) the scheduled reindex and I never seen again the primary key duplicated. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] DROP TYPE/DROP DOMAIN
Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane writes: No, a view is not a table. Try putting an index or trigger on it. According to that logic, a domain is not a type. Try putting a check constraint on it. But that's an additional feature, not a missing feature. I think the reason we are restrictive about the comparable cases for relations (pg_class entries) is that we use pg_class entries for a number of things that users see as unrelated or only weakly related. For example, indexes are not tables by any reasonable definition above the implementation level; sequences are tables only as an artifact of a particular implementation (which I think we'll someday have to abandon BTW); composite types surely aren't tables. It would be surprising for a composite type to be droppable by DROP TABLE. But domains *are* types, both to the user and to the implementation, and so I see no surprise factor in allowing DROP TYPE to work on them. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] contrib compilation probs
Peter Eisentraut wrote: Tom Lane writes: I was afraid it was something like that. Can we leave the directory structure as-is and just make the .o (and .d) files get built in the upper directory, that is gcc ... -o english_stem.o snowball/english_stem.c That will fail for a more basic reason: not all compilers support the -o option. I added sub-Makefiles. Christopher, try now, pls. -- Teodor Sigaev E-mail: [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] DROP TYPE/DROP DOMAIN
Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane writes: No, a view is not a table. Try putting an index or trigger on it. According to that logic, a domain is not a type. Try putting a check constraint on it. But that's an additional feature, not a missing feature. And added in 7.4: Add DOMAIN CHECK constraints (Rod) -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] truncate all?
This this a TODO? Keep in mind if we follow the syntax of VACUUM and
(7.4) CLUSTER, that the all-database truncate would just be TRUNACATE.
That seems very risky to me. I wonder if the risk is worth adding this
feature.
---
Robert Treat wrote:
On Mon, 2003-08-04 at 05:40, Shridhar Daithankar wrote:
On 4 Aug 2003 at 11:25, Andreas wrote:
Would it be possible to implement a truncate all that purges all tuples
from *all* tables, without taking account any rules or triggers, but
leaving all table structures and rules, triggers, functions, etc intact
(sequences do not need to reinitialized)?
As far as I understand, the no truncate if table is referenced change was
introduced to ensure database integrity. However, if the referencing table
is truncated, too, there should be no problem as far as foreign keys are
concerned, correct?
The rationale behind this suggestion is that in our project we need a
*quick* way to get rid of all the tuples in all tables in order to
accelerate the reinitialization of the database for our unit tests. This
needs to be done fairly often, and so the quicker the unit tests run, the
easier it will be to include many unit tests in our project, thus ensuring
that we can develop efficiently and safely in postgresql.
If you know of some other *quick* way to truncate all tables, please let us
know. BTW: Starting and later rolling back a transaction will not work, as
As a workaround, I would dump the schema to a file using pg_dump, drop the
database and recreate it from schema.
Will that do for you? Unfortunately that is not transaction safe and any
clients connected at that time needs to disconnect first. Hopefully you can do
that in the test environment.
Truncate isn't transaction safe either, so that shouldn't be a problem.
Proper syntax for his feature would seem like:
truncate table [cascade|restrict] ?
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 8: explain analyze is your friend
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
[HACKERS] problem with RH7.3 Pg7.3.4 binaries
(Not sure if hackers is the right place for this, but I'm not subscribed to all the lists!) The distributed 7.3.4 RPMs for RH 7.3 require libcrypto.so.3 and libssl.so.3, but there does not appear to be any official RH update for 7.3 containing these libs. I do have the latest RH openssl updates installed, but it only provides libssl.so.2 and libcrypto.so.2 and many many things break if I attempt to upgrade :-(, which is presumably why RH chose to backpatch security fixes rather than upgrade for this platform. I know building RPMs can be a major pain, but ISTM that builds should be published that don't break on vanilla installations. I'm prepared to help with fixing this if necessary. For now I've upgraded to 7.3.3 (the RPMs for this don't suffer the same problem on RH7.3). cheers andrew ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Thread-safe configuration option appears to misfunction
Peter Eisentraut wrote: Is it intended that libpq is always compiled with the so-called thread-safe compiler option, regardless of whether I used --enable-thread-thing? It certainly should not be doing that, but my OS has no thread flags, so I am not seeing it here. What exactly do you see? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] problem with RH7.3 Pg7.3.4 binaries
Andrew Dunstan wrote: I know building RPMs can be a major pain, but ISTM that builds should be published that don't break on vanilla installations. I'm prepared to help with fixing this if necessary. For now I've upgraded to 7.3.3 (the RPMs for this don't suffer the same problem on RH7.3). Sorry, that's my fault, not Lamar's. I built the 7.3 RPMs for him. Unfortunately I don't have a plain vanilla installation available -- I had forgotten that I upgraded ssl to something non-standard :( Perhaps if you have a vanilla 7.3 machine available, you could build new 7.3 RPMs from the source RPM and give them to Lamar for distribution? Joe ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Thread-safe configuration option appears to misfunction
Bruce Momjian writes: Peter Eisentraut wrote: Is it intended that libpq is always compiled with the so-called thread-safe compiler option, regardless of whether I used --enable-thread-thing? It certainly should not be doing that, but my OS has no thread flags, so I am not seeing it here. What exactly do you see? It's using -D_REENTRANT etc. (linux template) when compiling libpq. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Thread-safe configuration option appears to
--On Monday, August 04, 2003 17:54:41 +0200 Peter Eisentraut [EMAIL PROTECTED] wrote: Bruce Momjian writes: Peter Eisentraut wrote: Is it intended that libpq is always compiled with the so-called thread-safe compiler option, regardless of whether I used --enable-thread-thing? It certainly should not be doing that, but my OS has no thread flags, so I am not seeing it here. What exactly do you see? It's using -D_REENTRANT etc. (linux template) when compiling libpq. I think we WANT to do that for libpq so it can be used in a threaded app, since there is no libc_r on Linux to the best of my knowledge. I intend that to happen on UnixWare as well. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] truncate all?
I agree, a plain truncate blasting a whole database is a very bad thing.
however, truncate with cascade would be quite useful.
On Mon, 4 Aug 2003, Bruce Momjian wrote:
This this a TODO? Keep in mind if we follow the syntax of VACUUM and
(7.4) CLUSTER, that the all-database truncate would just be TRUNACATE.
That seems very risky to me. I wonder if the risk is worth adding this
feature.
---
Robert Treat wrote:
On Mon, 2003-08-04 at 05:40, Shridhar Daithankar wrote:
On 4 Aug 2003 at 11:25, Andreas wrote:
Would it be possible to implement a truncate all that purges all
tuples
from *all* tables, without taking account any rules or triggers, but
leaving all table structures and rules, triggers, functions, etc intact
(sequences do not need to reinitialized)?
As far as I understand, the no truncate if table is referenced change was
introduced to ensure database integrity. However, if the referencing table
is truncated, too, there should be no problem as far as foreign keys are
concerned, correct?
The rationale behind this suggestion is that in our project we need a
*quick* way to get rid of all the tuples in all tables in order to
accelerate the reinitialization of the database for our unit tests. This
needs to be done fairly often, and so the quicker the unit tests run, the
easier it will be to include many unit tests in our project, thus ensuring
that we can develop efficiently and safely in postgresql.
If you know of some other *quick* way to truncate all tables, please let us
know. BTW: Starting and later rolling back a transaction will not work, as
As a workaround, I would dump the schema to a file using pg_dump, drop the
database and recreate it from schema.
Will that do for you? Unfortunately that is not transaction safe and any
clients connected at that time needs to disconnect first. Hopefully you can do
that in the test environment.
Truncate isn't transaction safe either, so that shouldn't be a problem.
Proper syntax for his feature would seem like:
truncate table [cascade|restrict] ?
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 8: explain analyze is your friend
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] truncate all?
Bruce Momjian [EMAIL PROTECTED] writes: This this a TODO? Keep in mind if we follow the syntax of VACUUM and (7.4) CLUSTER, that the all-database truncate would just be TRUNACATE. That seems very risky to me. I wonder if the risk is worth adding this feature. I wouldn't care for that either. The prior suggestion of TRUNCATE tab CASCADE (to truncate any tables with FK dependencies on the original target, instead of failing) seems more reasonable. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Thread-safe configuration option appears to misfunction
We decided to make separate thread/nonthread libraries if the threading requires any special flags --- we haven't done that yet, and only configure controls it. --- Larry Rosenman wrote: --On Monday, August 04, 2003 17:54:41 +0200 Peter Eisentraut [EMAIL PROTECTED] wrote: Bruce Momjian writes: Peter Eisentraut wrote: Is it intended that libpq is always compiled with the so-called thread-safe compiler option, regardless of whether I used --enable-thread-thing? It certainly should not be doing that, but my OS has no thread flags, so I am not seeing it here. What exactly do you see? It's using -D_REENTRANT etc. (linux template) when compiling libpq. I think we WANT to do that for libpq so it can be used in a threaded app, since there is no libc_r on Linux to the best of my knowledge. I intend that to happen on UnixWare as well. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Thread-safe configuration option appears to
--On Monday, August 04, 2003 12:30:32 -0400 Bruce Momjian [EMAIL PROTECTED] wrote: We decided to make separate thread/nonthread libraries if the threading requires any special flags --- we haven't done that yet, and only configure controls it. That will be a POLA (principle of least astonishment) violation on UnixWare. LER - -- Larry Rosenman wrote: --On Monday, August 04, 2003 17:54:41 +0200 Peter Eisentraut [EMAIL PROTECTED] wrote: Bruce Momjian writes: Peter Eisentraut wrote: Is it intended that libpq is always compiled with the so-called thread-safe compiler option, regardless of whether I used --enable-thread-thing? It certainly should not be doing that, but my OS has no thread flags, so I am not seeing it here. What exactly do you see? It's using -D_REENTRANT etc. (linux template) when compiling libpq. I think we WANT to do that for libpq so it can be used in a threaded app, since there is no libc_r on Linux to the best of my knowledge. I intend that to happen on UnixWare as well. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] truncate all?
Guys, I wouldn't care for that either. The prior suggestion of TRUNCATE tab CASCADE (to truncate any tables with FK dependencies on the original target, instead of failing) seems more reasonable. I agree with Tom ... even the idea of a TRUNCATE ALL makes me nervous. If we had such a feature, I'd advocate that it be superuser only. As for TRUNCATE CASCADE or similar improvements, I agree that they could be convenient ... but are easily worked around currently. So I wouldn't object to putting TRUNCATE CASCADE on the todo list, but would argue that it be left to the people who asked for it to implement it. As far as -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] 7.4 COPY BINARY Format Change
Tom, Tom Lane writes: Lee Kindness [EMAIL PROTECTED] writes: However, is COPY BINARY meant/designed to be used as transfer or backup mechanism? I think you're overlooking a key consideration: COPY BINARY is not an isolated feature anymore. By design it uses the same data representations as are used for binary query parameters and results in the rest of the 7.4 FE/BE protocol. Yeah, what i've overlooked is that an implementation detail now forms part of an external interface into PostgreSQL - this is a major change. I could see some value in providing byte-swapping routines in libpq to convert between local and network representations for integers and floats. The underlying facilities (ntohl etc) are readily available, of course, but it's a small matter that is easy to get wrong. I'm not sure it's worth packaging up COPY BINARY logic per se. I think you'd end up with an API not materially simpler than dealing with the format directly. And I'm unconvinced it'd actually be used widely, whereas I do expect binary transfer of individual values to be common. Would I be right is guessing a binary CURSOR would return in values in the same format as a binary COPY, hence your expectation of more individual transfers/conversions? Actually with the new FE/BE protocol there is little call for the binary cursor now, yeah? What I proposed in my email yesterday is really just completing the new functions (PQnfields, PQputCopyData, PQgetCopyData and friends) described at: http://developer.postgresql.org/docs/postgres/libpq-copy.html so they don't stop at just giving you a blob of binary data and saying it has n fields - functions would be available to iterate over the fields and get the data out in a format which is immediately useful. Without this do you not think PQgetCopyData is of limited use except for being used by psql (which I guess isn't using it yet). Same for the writing functions. This is slightly different from my earlier example (on the connection rather than file-based) but functionally similar. BTW, do you have any examples of using PQgetCopyData - none in the source and can't find anything with Google. Regards, Lee. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Thread-safe configuration option appears to
Larry Rosenman wrote: --On Monday, August 04, 2003 12:30:32 -0400 Bruce Momjian [EMAIL PROTECTED] wrote: We decided to make separate thread/nonthread libraries if the threading requires any special flags --- we haven't done that yet, and only configure controls it. That will be a POLA (principle of least astonishment) violation on UnixWare. When we have the capability to do dual library builds, we might have a way to specify a threading flag that will apply to the main libpq and not create a libpq_r. If it is a good flag, can we use it in the template file for all compiling? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Thread-safe configuration option appears to misfunction
OK, I fixed a number of problems in configure with threads --- please give it a try now. Thanks. --- Peter Eisentraut wrote: Bruce Momjian writes: Peter Eisentraut wrote: Is it intended that libpq is always compiled with the so-called thread-safe compiler option, regardless of whether I used --enable-thread-thing? It certainly should not be doing that, but my OS has no thread flags, so I am not seeing it here. What exactly do you see? It's using -D_REENTRANT etc. (linux template) when compiling libpq. -- Peter Eisentraut [EMAIL PROTECTED] -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] truncate all?
On Mon, 2003-08-04 at 12:19, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
This this a TODO? Keep in mind if we follow the syntax of VACUUM and
(7.4) CLUSTER, that the all-database truncate would just be TRUNACATE.
That seems very risky to me. I wonder if the risk is worth adding this
feature.
I wouldn't care for that either. The prior suggestion of TRUNCATE tab
CASCADE (to truncate any tables with FK dependencies on the original
target, instead of failing) seems more reasonable.
Actually there seems to be an ancillary issue here:
21809=# truncate exception;
ERROR: TRUNCATE cannot be used as table exception_notice_map references
this one via foreign key constraint $1
21809=# TRUNCATE exception_notice_map ;
TRUNCATE TABLE
21809=# truncate exception;
ERROR: TRUNCATE cannot be used as table exception_notice_map references
this one via foreign key constraint $1
21809=# select count(*) from exception_notice_map;
count
---
0
(1 row)
21809=#
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] problem with RH7.3 Pg7.3.4 binaries
On Monday 04 August 2003 11:53, Joe Conway wrote: Andrew Dunstan wrote: I know building RPMs can be a major pain, but ISTM that builds should be published that don't break on vanilla installations. I'm prepared to help with fixing this if necessary. For now I've upgraded to 7.3.3 (the RPMs for this don't suffer the same problem on RH7.3). Sorry, that's my fault, not Lamar's. I built the 7.3 RPMs for him. Unfortunately I don't have a plain vanilla installation available -- I had forgotten that I upgraded ssl to something non-standard :( Perhaps if you have a vanilla 7.3 machine available, you could build new 7.3 RPMs from the source RPM and give them to Lamar for distribution? Until vanilla-built RH7.3 RPMs are available, I've removed them from the FTP site. I don't have an RH7.3 installation readily available for building. Joe, the RHAS binaries won't have this problem, right? To prevent this in the future, I'm going to state that anyone who wants to build RPMs for distribution needs to do so with a fully up to date vanilla installation of the target OS. Since I do this myself for whatever RPMs I'm personally building, it was an easy assumption to make that everyone would do this. My apologies. A minor rant: I seem to vacillate between providing only one set of RPMs versus providing whatever sets people can build for me. There is a definite tradeoff between having lots of sets available and having only good sets available. While I do my best to ensure only good sets are available, I am not able to test every set that is built. That is one reason I've not begun GPG-signing my RPMs -- if you want certified RPMs build them yourself. It isn't that hard. And when people are so impatient for RPMsets, then complain that the set didn't work -- well, it isn't the most encouraging thing in the world. You want guaranteed RPMs that will install on your machine the day of the release? You have three choices: build them yourself, pay someone to build them, or wait until the official set is available. My rate for building RPMs under those conditions is $100 per hour. (and I have been paid that rate before.) But the official set will only get uploaded once I've had the time to build it and test it. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] problem with RH7.3 Pg7.3.4 binaries
Lamar Owen wrote: Joe, the RHAS binaries won't have this problem, right? I don't think so -- the server I built those on is very much vanilla RHAS. But then this raises a question in my mind -- is vanilla a fully updated vanilla or off the original CDs vanilla? To prevent this in the future, I'm going to state that anyone who wants to build RPMs for distribution needs to do so with a fully up to date vanilla installation of the target OS. Since I do this myself for whatever RPMs I'm personally building, it was an easy assumption to make that everyone would do this. My apologies. Sorry -- I'll be more cognizant of that in the future. Joe ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Thread-safe configuration option appears to
--On Monday, August 04, 2003 12:50:31 -0400 Bruce Momjian [EMAIL PROTECTED] wrote: Larry Rosenman wrote: --On Monday, August 04, 2003 12:30:32 -0400 Bruce Momjian [EMAIL PROTECTED] wrote: We decided to make separate thread/nonthread libraries if the threading requires any special flags --- we haven't done that yet, and only configure controls it. That will be a POLA (principle of least astonishment) violation on UnixWare. When we have the capability to do dual library builds, we might have a way to specify a threading flag that will apply to the main libpq and not create a libpq_r. If it is a good flag, can we use it in the template file for all compiling? I **THINK** so. What I'm thinking of is -D_REENTRANT for UnixWare especially for libpq. the --with-threads would cause ecpg to be compiled/linked as -lpthread in addition to -D_REENTRANT LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Thread-safe configuration option appears to
Larry Rosenman wrote: We decided to make separate thread/nonthread libraries if the threading requires any special flags --- we haven't done that yet, and only configure controls it. That will be a POLA (principle of least astonishment) violation on UnixWare. When we have the capability to do dual library builds, we might have a way to specify a threading flag that will apply to the main libpq and not create a libpq_r. If it is a good flag, can we use it in the template file for all compiling? I **THINK** so. What I'm thinking of is -D_REENTRANT for UnixWare especially for libpq. the --with-threads would cause ecpg to be compiled/linked as -lpthread in addition to -D_REENTRANT Nope, we are not going to link with -lpthread unless it is enabled in configure. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Thread-safe configuration option appears to
--On Monday, August 04, 2003 13:11:45 -0400 Bruce Momjian [EMAIL PROTECTED] wrote: Larry Rosenman wrote: We decided to make separate thread/nonthread libraries if the threading requires any special flags --- we haven't done that yet, and only configure controls it. That will be a POLA (principle of least astonishment) violation on UnixWare. When we have the capability to do dual library builds, we might have a way to specify a threading flag that will apply to the main libpq and not create a libpq_r. If it is a good flag, can we use it in the template file for all compiling? I **THINK** so. What I'm thinking of is -D_REENTRANT for UnixWare especially for libpq. the --with-threads would cause ecpg to be compiled/linked as -lpthread in addition to -D_REENTRANT Nope, we are not going to link with -lpthread unless it is enabled in configure. Right. but libpq should be built with -D_REENTRANT on UnixWare regardless of the --with-threads. Read what I said above. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] problem with RH7.3 Pg7.3.4 binaries
On Monday 04 August 2003 13:00, Joe Conway wrote: I don't think so -- the server I built those on is very much vanilla RHAS. But then this raises a question in my mind -- is vanilla a fully updated vanilla or off the original CDs vanilla? I've thus far used the definition that it is a fully-updated install, using the OS vendor's update packages that are dependencies of PostgreSQL. Updating to, say, a later KDE, or GNUcash, or whatnot is OK. But core libraries that PostgreSQL uses need to stay vanilla-updated. Sorry -- I'll be more cognizant of that in the future. Hey, don't worry about it. I should have checked: that IS my responsibility. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Thread-safe configuration option appears to
Larry Rosenman wrote: --On Monday, August 04, 2003 13:11:45 -0400 Bruce Momjian [EMAIL PROTECTED] wrote: Larry Rosenman wrote: We decided to make separate thread/nonthread libraries if the threading requires any special flags --- we haven't done that yet, and only configure controls it. That will be a POLA (principle of least astonishment) violation on UnixWare. When we have the capability to do dual library builds, we might have a way to specify a threading flag that will apply to the main libpq and not create a libpq_r. If it is a good flag, can we use it in the template file for all compiling? I **THINK** so. What I'm thinking of is -D_REENTRANT for UnixWare especially for libpq. the --with-threads would cause ecpg to be compiled/linked as -lpthread in addition to -D_REENTRANT Nope, we are not going to link with -lpthread unless it is enabled in configure. Right. but libpq should be built with -D_REENTRANT on UnixWare regardless of the --with-threads. Well, let's see what additional functionality we need. I am not feeling too friendly on SCO/Unixware right now to jump through hoops. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Thread-safe configuration option appears to
--On Monday, August 04, 2003 13:19:57 -0400 Bruce Momjian [EMAIL PROTECTED] wrote: Larry Rosenman wrote: --On Monday, August 04, 2003 13:11:45 -0400 Bruce Momjian [EMAIL PROTECTED] wrote: Larry Rosenman wrote: We decided to make separate thread/nonthread libraries if the threading requires any special flags --- we haven't done that yet, and only configure controls it. That will be a POLA (principle of least astonishment) violation on UnixWare. When we have the capability to do dual library builds, we might have a way to specify a threading flag that will apply to the main libpq and not create a libpq_r. If it is a good flag, can we use it in the template file for all compiling? I **THINK** so. What I'm thinking of is -D_REENTRANT for UnixWare especially for libpq. the --with-threads would cause ecpg to be compiled/linked as -lpthread in addition to -D_REENTRANT Nope, we are not going to link with -lpthread unless it is enabled in configure. Right. but libpq should be built with -D_REENTRANT on UnixWare regardless of the --with-threads. Well, let's see what additional functionality we need. I am not feeling too friendly on SCO/Unixware right now to jump through hoops. Let's not go there. I'm not involved in the IP fight, but I am a USER on that platform, and SCO is thinking SERIOUSLY about shipping PG on the Platform as part of their extensions offering. What the fr*** harm is it in passing -D_REENTRANT into the libpq build on UnixWare irregardless of the --with-threads* flag? Same argument for allowing the PORT to determine whether to allow/permit the full pathname in for DT_SONAME. Let's not run people off because of what the damn lawyers are doing. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] 7.4 COPY BINARY Format Change
Lee Kindness [EMAIL PROTECTED] writes: Would I be right is guessing a binary CURSOR would return in values in the same format as a binary COPY, hence your expectation of more individual transfers/conversions? Actually with the new FE/BE protocol there is little call for the binary cursor now, yeah? Binary cursors per se are obsolete --- you can get the result of any query in binary form, if you ask politely. And you can send data in binary form, too, using parameters. I have not gotten around to benchmarking a prepared INSERT with binary parameters against a binary COPY, but I expect the differential is not nearly as bad as it is for a source-form INSERT. It could well be that binary COPY is obsolete for the purposes you're using it for. so they don't stop at just giving you a blob of binary data and saying it has n fields - functions would be available to iterate over the fields and get the data out in a format which is immediately useful. You can iterate over the fields of a text COPY and get the data out, too, if you think it useful. I haven't seen a huge call for support for that, and so I don't believe it's important for binary COPY either. I do see a need for converting individual binary data values in the context of query parameters and results. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] problem with RH7.3 Pg7.3.4 binaries
I agree with the definition of vanilla install below. I can't use the machine I was upgrading to build, unfortunately. Its a production machine I am prepping, (and is missing stuff the build process needs even if I wanted to monkey with it), which is precisely why I wanted to install from RPMs rather than just saying screw it and installing from a source tarball. I will see if I can get the old machine currently mouldering away in my attic to run 7.3 and build with it, maybe some time this week. (It's time like these you appreciate having lots of bandwidth to download ISOs). andrew Lamar Owen wrote: On Monday 04 August 2003 13:00, Joe Conway wrote: I don't think so -- the server I built those on is very much vanilla RHAS. But then this raises a question in my mind -- is vanilla a fully updated vanilla or off the original CDs vanilla? I've thus far used the definition that it is a fully-updated install, using the OS vendor's update packages that are dependencies of PostgreSQL. Updating to, say, a later KDE, or GNUcash, or whatnot is OK. But core libraries that PostgreSQL uses need to stay vanilla-updated. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Who is maintaining the dbf2pg contrib utility?
Is anyone actively maintaining the dbase/dbf2pg utility in the contrib library? I have a couple of patches to fix bugs and one feature enhancement to suggest, but I'm not sure of the proper procedure for a contrib package. I've tried contacting the author at the address given in the package ([EMAIL PROTECTED]) with no response, but maybe that's an old address. -- Mike Nolan ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] problem with RH7.3 Pg7.3.4 binaries
Joe Conway wrote: Lamar Owen wrote: I've thus far used the definition that it is a fully-updated install, using the OS vendor's update packages that are dependencies of PostgreSQL. Updating to, say, a later KDE, or GNUcash, or whatnot is OK. But core libraries that PostgreSQL uses need to stay vanilla-updated. I'll have to check, but I'd guess that the RHAS I built on was pretty close to off the original CDs, i.e. not updated. I'll let you know. I just checked, and the RHAS that I built the RPMs on is pretty close to original, other than kernel and some driver updates. I'll let you decide whether to pull them or not, but they don't meet your fully-updated install criterion. Joe ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Thread-safe configuration option appears to
Larry Rosenman [EMAIL PROTECTED] writes: SCO is thinking SERIOUSLY about shipping PG on the Platform as part of their extensions offering. Why, how nice of them. I don't intend to lift a finger to help. regards, tom lane ---(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] Thread-safe configuration option appears to
--On Monday, August 04, 2003 14:06:34 -0400 Tom Lane [EMAIL PROTECTED] wrote: Larry Rosenman [EMAIL PROTECTED] writes: SCO is thinking SERIOUSLY about shipping PG on the Platform as part of their extensions offering. Why, how nice of them. I don't intend to lift a finger to help. Grr. I guess I'll get off the lists now. regards, tom lane -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] problem with cache
hi, i have more problems with cache :( i wrote about it latter , but there was no answer. Because when i drop same relation its should be clean cache too, but postgres dont do it . Ist sad because i cant do reload db , i have errors :( what should i do ? ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Thread-safe configuration option appears to
On Mon, 4 Aug 2003, Tom Lane wrote: Larry Rosenman [EMAIL PROTECTED] writes: SCO is thinking SERIOUSLY about shipping PG on the Platform as part of their extensions offering. Why, how nice of them. I don't intend to lift a finger to help. I don't know, I can think of ONE finger I'd be willing to lift. But not to help really. :-) ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] problem with cache
On Mon, Aug 04, 2003 at 09:24:49PM +0200, ivan wrote: hi, i have more problems with cache :( i wrote about it latter , but there was no answer. Because when i drop same relation its should be clean cache too, but postgres dont do it . Ist sad because i cant do reload db , i have errors :( what should i do ? What do you mean by drop same relation? Is this SQL or you are hacking the backend? If the latter maybe you need something like RelationFlushBuffers() or RelationForgetRelation(). -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) The ability to monopolize a planet is insignificant next to the power of the source ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] problem with cache
drop relation = drop table or drop sequence etc I tryed RelationForgetRelation() but i dont working :( On Mon, 4 Aug 2003, Alvaro Herrera wrote: On Mon, Aug 04, 2003 at 09:24:49PM +0200, ivan wrote: hi, i have more problems with cache :( i wrote about it latter , but there was no answer. Because when i drop same relation its should be clean cache too, but postgres dont do it . Ist sad because i cant do reload db , i have errors :( what should i do ? What do you mean by drop same relation? Is this SQL or you are hacking the backend? If the latter maybe you need something like RelationFlushBuffers() or RelationForgetRelation(). -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) The ability to monopolize a planet is insignificant next to the power of the source ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] lower and upper not UTF-8 safe
The implementations of lower and upper in src/backend/utils/adt/oracle_compat.c use the single byte macros from ctype.h to alter individual bytes in the text string. If the text is UTF-8 encoded this is totally wrong, and will result in an invalid string that is no longer UTF-8. The code is basically unchanged in both 7.3.4 and CVS tip. I can see two options - remove access to these functions if the database is running UNICODE, or rewrite/extend them so the correct thing happens. The easiest way to do this is probably to convert the UTF-8 to a fixed width encoding (say UCS-4), perform the lower operation to get a new set of character indices, then convert back to UTF-8. The byte length of the output might even be different from the input, although I don't know of an example where this happens. At the very least, the documentation for lower and upper in the manual should warn the user not to use them in a UNICODE database. -- Julian Satchell [EMAIL PROTECTED] QinetiQ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] lower and upper not UTF-8 safe
Julian Satchell [EMAIL PROTECTED] writes: The implementations of lower and upper in src/backend/utils/adt/oracle_compat.c use the single byte macros from ctype.h to alter individual bytes in the text string. If the text is UTF-8 encoded this is totally wrong, and will result in an invalid string that is no longer UTF-8. Only if you use a locale that is assuming a character set that is not UTF8 but does have characters with the high bit set. I'm not sure that we can do anything to defend against locale/charset mismatch. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Thread-safe configuration option appears to
Would you send over a modified template/unixware and template/sco to at least allow threading when enabled --- see linux or freebsd for examples --- that is how we are enabling threading. Are you saying you want that flag without --enable-thread-safety? --- Larry Rosenman wrote: --On Monday, August 04, 2003 13:19:57 -0400 Bruce Momjian [EMAIL PROTECTED] wrote: Larry Rosenman wrote: --On Monday, August 04, 2003 13:11:45 -0400 Bruce Momjian [EMAIL PROTECTED] wrote: Larry Rosenman wrote: We decided to make separate thread/nonthread libraries if the threading requires any special flags --- we haven't done that yet, and only configure controls it. That will be a POLA (principle of least astonishment) violation on UnixWare. When we have the capability to do dual library builds, we might have a way to specify a threading flag that will apply to the main libpq and not create a libpq_r. If it is a good flag, can we use it in the template file for all compiling? I **THINK** so. What I'm thinking of is -D_REENTRANT for UnixWare especially for libpq. the --with-threads would cause ecpg to be compiled/linked as -lpthread in addition to -D_REENTRANT Nope, we are not going to link with -lpthread unless it is enabled in configure. Right. but libpq should be built with -D_REENTRANT on UnixWare regardless of the --with-threads. Well, let's see what additional functionality we need. I am not feeling too friendly on SCO/Unixware right now to jump through hoops. Let's not go there. I'm not involved in the IP fight, but I am a USER on that platform, and SCO is thinking SERIOUSLY about shipping PG on the Platform as part of their extensions offering. What the fr*** harm is it in passing -D_REENTRANT into the libpq build on UnixWare irregardless of the --with-threads* flag? Same argument for allowing the PORT to determine whether to allow/permit the full pathname in for DT_SONAME. Let's not run people off because of what the damn lawyers are doing. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Thread-safe configuration option appears to
Let's not go there. I'm not involved in the IP fight, but I am a USER on that platform, and SCO is thinking SERIOUSLY about shipping PG on the Platform as part of their extensions offering. What the fr*** harm is it in passing -D_REENTRANT into the libpq build on UnixWare irregardless of the --with-threads* flag? Same argument for allowing the PORT to determine whether to allow/permit the full pathname in for DT_SONAME. We did have a discussion on whether we should enable threading by default, and the issue was that we don't even have enough platforms supported at this point, so by running configure with the thread flag, you are asking us to generate a threaded libpq and ecpg, and we will fail if we can't. On BSD/OS, that flag does nothing (the binaries are the same), but we have the flag so people can know if their libs are thread-safe. I think the template files are the way to go at this point. If we support threads on all/most of our platforms, we can think about doing something by default. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Who is maintaining the dbf2pg contrib utility?
Good question. If you send over the patches, we will apply it to the version we ship. --- [EMAIL PROTECTED] wrote: Is anyone actively maintaining the dbase/dbf2pg utility in the contrib library? I have a couple of patches to fix bugs and one feature enhancement to suggest, but I'm not sure of the proper procedure for a contrib package. I've tried contacting the author at the address given in the package ([EMAIL PROTECTED]) with no response, but maybe that's an old address. -- Mike Nolan ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] problem with RH7.3 Pg7.3.4 binaries
On Monday 04 August 2003 13:57, Joe Conway wrote: I just checked, and the RHAS that I built the RPMs on is pretty close to original, other than kernel and some driver updates. I'll let you decide whether to pull them or not, but they don't meet your fully-updated install criterion. Hmmm... Tough call, but I think I'll leave them be, since they will install on a fully-updated installation. Although I can't imagine an RHAS install not updated, but that's a different topic. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Thread-safe configuration option appears to
As soon as a beta tarball shows up, I'll cut changes for UnixWare for --enable-threads, and also to do -D_REENTRANT anyway on UnixWare. What about Kean's change to allow absolute DT_SONAME's? Can that get applied, and used for SCO and UnixWare? LER --On Monday, August 04, 2003 18:16:02 -0400 Bruce Momjian [EMAIL PROTECTED] wrote: Let's not go there. I'm not involved in the IP fight, but I am a USER on that platform, and SCO is thinking SERIOUSLY about shipping PG on the Platform as part of their extensions offering. What the fr*** harm is it in passing -D_REENTRANT into the libpq build on UnixWare irregardless of the --with-threads* flag? Same argument for allowing the PORT to determine whether to allow/permit the full pathname in for DT_SONAME. We did have a discussion on whether we should enable threading by default, and the issue was that we don't even have enough platforms supported at this point, so by running configure with the thread flag, you are asking us to generate a threaded libpq and ecpg, and we will fail if we can't. On BSD/OS, that flag does nothing (the binaries are the same), but we have the flag so people can know if their libs are thread-safe. I think the template files are the way to go at this point. If we support threads on all/most of our platforms, we can think about doing something by default. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(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] contrib compilation probs
That will fail for a more basic reason: not all compilers support the -o option. I added sub-Makefiles. Christopher, try now, pls. Works perfectly. Thanks. Chris ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Building beta packaging fails ...
The Hermit Hacker [EMAIL PROTECTED] writes: Using the attached script, the build fails while trying ot tar up the distributions ... when its trying to build the tools tar file, error being that it can't find the src/data directory ... Why is it looking for src/data? I removed all the files in that directory last night as part of the --enable-recode deletion. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] boolean defaults
Hi, Is it possible to get a default value on a boolean column to be anything other than 't', 'f', true or false? eg. If I go 'default 3 1', that's resolved to default true. I just need to know for phpPgAdmin... Chris ---(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] Building beta packaging fails ...
GNUMakefile.in: opt_files := \ src/tools src/corba src/data src/tutorial \ src/bin/pgtclsh \ $(addprefix src/interfaces/, libpgtcl jdbc) \ $(addprefix src/pl/, plperl plpython tcl) I take it then, that src/data shoudl be removed from there too? On Mon, 4 Aug 2003, Tom Lane wrote: The Hermit Hacker [EMAIL PROTECTED] writes: Using the attached script, the build fails while trying ot tar up the distributions ... when its trying to build the tools tar file, error being that it can't find the src/data directory ... Why is it looking for src/data? I removed all the files in that directory last night as part of the --enable-recode deletion. regards, tom lane Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: [EMAIL PROTECTED] secondary: [EMAIL PROTECTED]|postgresql}.org ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Thread-safe configuration option appears to
--On Monday, August 04, 2003 23:01:32 -0400 Bruce Momjian [EMAIL PROTECTED] wrote: Larry Rosenman wrote: As soon as a beta tarball shows up, I'll cut changes for UnixWare for --enable-threads, and also to do -D_REENTRANT anyway on UnixWare. OK. What about Kean's change to allow absolute DT_SONAME's? Can that get applied, and used for SCO and UnixWare? Can you verify if it needed only because they honor LD_LIBRARY_PATH on suid executables? If so, I would like to have something that is only in the template file and Makefile.shlib. I think that is possible. and since there is no ld.so.conf/ldconfig type caching at all. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
