Re: [HACKERS] [PATCHES] Chinese GB18030 support is implemented!
[pgsql-announce removed and pgsql-hackers added] I have applied your patches with small corrections. Please grab the latest source and let me know if something is wrong. Thanks. -- Tatsuo Ishii > Hi Ishii-san, > > The patches are attached.Please apply it. > > Thanks, > Bill > > Tatsuo Ishii wrote: > > >>Hello, > >> > >>As postgresql is widely used in the world,many Chinese users are looking > >>forward to use such a high performanced database management > >>system.However since the Chinese new codepage standard GB18030 is not > >>completely supported,postgresql is limitted to be used in China. > >> > >>Now I have managed to implement the GB18030 support upon the latest > >>version,so the following functions are added after the patches are added. > >> > >>-Chinese GB18030 encoding is available on front-end side,while on > >>backend side,EUC_CN or MIC is used. > >>-Encoding convertion between MIC and GB18030 is implement. > >>-GB18030 locale support is available on front-end side. > >>-GB18030 locale test is added. > >> > >>Any help for testing with these patches and sugguestions for GB18030 > >>support are greatly appreciated. > >> > > > >We need to apply your pacthes to the current source tree(we are not > >allowed to add new feature stable source tree). Your pacthes for > >encnames.c pg_wchar.h and wchar.c are rejected due to the difference > >between 7.2 and current. > > > >Can you give me patches encnames.c pg_wchar.h and wchar.c against > >current? > > > >Unicode conversion map staffs ISO10646-GB18030.TXT utf8_to_gb18030.map > >UCS_to_GB18030.pl and gb18030_to_utf8.map are looks good for > >current. So I will apply them. > >-- > >Tatsuo Ishii > > > -- > /---/ > (Bill Huang) > E-mail:[EMAIL PROTECTED] > Cell phone:090-9979-4631 > /---/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] PostGres Doubt
On Wed, 2002-06-12 at 19:38, Tom Lane wrote: > David Ford <[EMAIL PROTECTED]> writes: > > So reentrancy in libpq basically is put on hold until 7.3. > > Only if you insist on using "crypt", which is deprecated anyway. > md5 is the preferred encryption method. > > My feeling about the proposed patch was that crypt is now a legacy auth > method, and it's not clear that we should create platform/library > dependencies just to support making multiple connections simultaneously > under crypt auth. (Note that *using* connections concurrently is not > at issue, only whether you can execute the authentication phase of > startup concurrently.) can't this be solved by simple locking ? I know that postgres team can do locking properly ;) -- Hannu ---(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] Feature request: Truncate table
On Thu, 2002-06-13 at 03:47, Christopher Kings-Lynne wrote: > > > What is a TRUNCATE TABLE but a drop create anyway? Is there some > > > technical difference? > > > > > It doesn't kill indexes/triggers/constraints/Foreign Key Stuff, etc. > > Hrm - last time I checked it did... Two questions : When was the last time ? It did what ? - Hannu ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Feature request: Truncate table
> > Hrm - last time I checked it did... > > Two questions : > > When was the last time ? 7.1 > It did what ? Drops triggers and stuff. OK, I did a check and it looks like it's fixed in 7.2 at least. Sorry for the false alarm... Chris ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Feature request: Truncate table
Christopher Kings-Lynne wrote: > > > > Hrm - last time I checked it did... > > > > Two questions : > > > > When was the last time ? > > 7.1 > > > It did what ? > > Drops triggers and stuff. > > OK, I did a check and it looks like it's fixed in 7.2 at least. Sorry for > the false alarm... It has never "dropped triggers and stuff", so there was nothing to fix. All TRUNCATE TABLE has ever done, since the patch was submitted, was to truncate the underlying relation file and the associated index files, and reinitialize the indexes. It has been changed to be disallowed in transactions involving tables not created in the same transaction, but that's about it. People have argued that if there are *RI* triggers on a table, that TRUNCATE should be disallowed, as in Oracle. But TRUNCATE from inception to date has never dropped triggers... Mike Mascari [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] PostGres Doubt
On Wed, Jun 12, 2002 at 11:00:26AM -0700, Dann Corbit wrote: > Or run concurrent queries queries at the same time? Or later discover > the need to do so? I didn't say multi-threading is bad. I just don't think your answer helped him much. > I posted the problems to this list long ago. I wanted to use ECPG and > discovered it was a joke. Do a search through the list and you will > find a half dozen complaints. If you use this kind of language I wonder if anyone ever reacted on any complaint you send. > Then why not do it. I looked at doing it myself, but the implementation Gotta like that attidude. Did you read aynthing about us not wanting to make ecpg multi-threaded? > of embedded SQL is totally nonstandard and uses global structures and What's that about? Our parser is nonstandard? Please if you expect any more answers, how about adding some facts and not just talking badly about people. > > Oh great! Talking about valuable comments. Ever bothered to > > even ask if > > they are using triggers, constraints, etc. before coming with such a > > proposal? > > I would assume that they would use their brain. Why? You don't use it either. I'm sorry, but I cannot stand this kind of behaviour. Michael -- Michael Meskes [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(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] PostGres Doubt
On Wed, Jun 12, 2002 at 11:46:47AM -0700, Dann Corbit wrote: > I should apologize for being rather harsh about embedded SQL for > PostgreSQL. Also about being harsh about the people? Okay, apologies accepted. > I actually spent a great deal of effort trying to write some tools using > the PostgreSQL version of ECPG, and found fatal flaws that threw away a Which ones? If it's just SQLDA, this is pretty well documented. Yes, the feature is missing, but we all have only limited time for postgresql work. > A reentrant version of ECPG that uses SQLCA and SQLDA like Oracle or Rdb > or DB/2 or any of the professional database systems. The last time I used Oracle it used SQLCA in a very similar way as ECPG does. Michael -- Michael Meskes [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] PostGres Doubt
On Wed, Jun 12, 2002 at 05:42:24PM -0400, Bruce Momjian wrote: > You are actually the first person to complain about this, as far as I > can remember. Yup. I cannot remember any other person either. And since nobody complained, nobody worked on this. :-) Michael -- Michael Meskes [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(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] PostGres Doubt
On Wed, Jun 12, 2002 at 06:19:57PM -0400, Bruce Momjian wrote: > > I doubt if many people are using it then. There is a NIST SQL suite > > which should be run against it. Have you heard of it? It is a > > standardization for embedded SQL [and other facets of the SQL langauge]. > > I think it would be very nice if the PostgreSQL team should try to > > incorporte the whole thing as part of their validation suite. The > > project the uses embedded sql is in the folder /pc under the nist main > > folder. Here is an example from that project that use sqlca: > > Oh, that seems easy. I know Michael will know the answer. Actually I didn't know that test suite. But I will surely look at it. Michael -- Michael Meskes [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Integrating libpqxx
On Wed, Jun 12, 2002 at 10:41:32PM -0400, Tom Lane wrote: > > I'm thinking we should just import the current state of the files > and not worry about preserving their change history. Fine with me, if that's easier. I just thought it might be "nice to have" but I can't think of any compelling reason to go to any trouble. Jeroen ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] Making serial survive pg_dump
Currently serial is dumped as a sequence and appropriate default statement. With my upcoming dependency patch serials depend on the appropriate column. Drop the column (or table) and the sequence goes with it. The depencency information does not survive the pg_dump / restore process however as it's recreated as the table and individual sequence. I see 2 options for carrying the information. Store sequence information in the SERIAL creation statement: CREATE TABLE tab (col1 SERIAL(, )); Or store the dependency information in the sequence: CREATE SEQUENCE ... REQUIRES COLUMN ; The former makes a lot more sense, and it's nice that the sequence information is in one place. -- Rod ---(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] Integrating libpqxx
On Thu, 13 Jun 2002, Jeroen T. Vermeulen wrote: > On Wed, Jun 12, 2002 at 10:41:32PM -0400, Tom Lane wrote: > > > > I'm thinking we should just import the current state of the files > > and not worry about preserving their change history. > > Fine with me, if that's easier. I just thought it might be "nice to have" > but I can't think of any compelling reason to go to any trouble. Jeroen ... can you send me a copy of the CVSROOT for this? Email will work ... if we can, I would like to save the development history, and I *think* I can ... ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] Chinese GB18030 support is implemented!
Hi Ishii-san, Great!Thanks for your help. Would you please update the Makefile under Unicode?it should be updated for GB18030. Best regards, Bill Tatsuo Ishii wrote: >[pgsql-announce removed and pgsql-hackers added] > >I have applied your patches with small corrections. Please grab the >latest source and let me know if something is wrong. > >Thanks. >-- >Tatsuo Ishii > >>Hi Ishii-san, >> >>The patches are attached.Please apply it. >> >>Thanks, >>Bill >> >>Tatsuo Ishii wrote: >> Hello, As postgresql is widely used in the world,many Chinese users are looking forward to use such a high performanced database management system.However since the Chinese new codepage standard GB18030 is not completely supported,postgresql is limitted to be used in China. Now I have managed to implement the GB18030 support upon the latest version,so the following functions are added after the patches are added. -Chinese GB18030 encoding is available on front-end side,while on backend side,EUC_CN or MIC is used. -Encoding convertion between MIC and GB18030 is implement. -GB18030 locale support is available on front-end side. -GB18030 locale test is added. Any help for testing with these patches and sugguestions for GB18030 support are greatly appreciated. >>>We need to apply your pacthes to the current source tree(we are not >>>allowed to add new feature stable source tree). Your pacthes for >>>encnames.c pg_wchar.h and wchar.c are rejected due to the difference >>>between 7.2 and current. >>> >>>Can you give me patches encnames.c pg_wchar.h and wchar.c against >>>current? >>> >>>Unicode conversion map staffs ISO10646-GB18030.TXT utf8_to_gb18030.map >>>UCS_to_GB18030.pl and gb18030_to_utf8.map are looks good for >>>current. So I will apply them. >>>-- >>>Tatsuo Ishii >>> >>-- >>/---/ >>(Bill Huang) >>E-mail:[EMAIL PROTECTED] >>Cell phone:090-9979-4631 >>/---/ >> -- Bill Huang (81)-3-3257-0417 Red Hat K.K. http://www.jp.redhat.com ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] New string functions; initdb required
Thanks for the info! I have a question... > As usual: ( ) + * [ ] | > Instead of dot . there is underscore _ > There is % to mean .* just like LIKE > There is no ? or ^ or $ > Regular expressions match the whole string, as if there were an > implicit ^ before and $ after the pattern. You have to add % if > you want to match anywhere in a string. Hmm. So if there are no explicit anchors then there must be a slightly different syntax for the regular-expression version of the substring() function? Otherwise, substrings would always have to start from the first character, right? Percents and underscores carried over from LIKE are really annoying. I'll think about implementing an expression rewriter to convert SQL99 to our modern regexp syntax. - Thomas ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Making serial survive pg_dump
"Rod Taylor" <[EMAIL PROTECTED]> writes: > Store sequence information in the SERIAL creation statement: > CREATE TABLE tab (col1 SERIAL(, )); This is wrong because it loses the separation between schema and data. I do agree that it would be nice if pg_dump recognized serial columns and dumped them as such --- but the separate setval call is still the appropriate technique for messing with the sequence contents. We do not need a syntax extension in CREATE. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] New string functions; initdb required
> Also, you neglected to add PLACING to the gram.y keyword category lists. I just now added and committed it as a reserved word. - Thomas ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Integrating libpqxx
On Thu, Jun 13, 2002 at 09:15:05AM -0300, Marc G. Fournier wrote: > > Jeroen ... can you send me a copy of the CVSROOT for this? Email will > work ... if we can, I would like to save the development history, and I > *think* I can ... I already sent one to Bruce last night, IIRC. Jeroen ---(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] Integrating libpqxx
Jeroen T. Vermeulen wrote: > On Thu, Jun 13, 2002 at 09:15:05AM -0300, Marc G. Fournier wrote: > > > > Jeroen ... can you send me a copy of the CVSROOT for this? Email will > > work ... if we can, I would like to save the development history, and I > > *think* I can ... > > I already sent one to Bruce last night, IIRC. I just bounced it over to Marc. -- 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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Integrating libpqxx
got it ... will try and incorporate it and see what I can come up with ... thanks :) On Thu, 13 Jun 2002, Bruce Momjian wrote: > Jeroen T. Vermeulen wrote: > > On Thu, Jun 13, 2002 at 09:15:05AM -0300, Marc G. Fournier wrote: > > > > > > Jeroen ... can you send me a copy of the CVSROOT for this? Email will > > > work ... if we can, I would like to save the development history, and I > > > *think* I can ... > > > > I already sent one to Bruce last night, IIRC. > > I just bounced it over to Marc. > > -- > 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 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] Win32 port
I have added the recent threads discussing a Win32 port to CVS TODO.detail, and have added an item on the TODO list: * Create native Win32 port [win32] -- 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 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] PostGres Doubt
> -Original Message- > From: Michael Meskes [mailto:[EMAIL PROTECTED]] > Sent: Thursday, June 13, 2002 3:06 AM > To: [EMAIL PROTECTED] > Subject: Re: [HACKERS] PostGres Doubt > > > On Wed, Jun 12, 2002 at 11:46:47AM -0700, Dann Corbit wrote: > > I should apologize for being rather harsh about embedded SQL for > > PostgreSQL. > > Also about being harsh about the people? Okay, apologies accepted. > > > I actually spent a great deal of effort trying to write > some tools using > > the PostgreSQL version of ECPG, and found fatal flaws that > threw away a > > Which ones? If it's just SQLDA, this is pretty well > documented. Yes, the > feature is missing, but we all have only limited time for postgresql > work. Allow me to apologize again. I have clearly gotten off on the wrong foot here. In 6 months of 8 hour days, I would not be able to create a tool with the functionality that you have provided. It is an amazing piece of work. The point I was (badly) trying to make is that because of some of the limitations of PostgreSQL's ECPG it is impossible for me to use it. Now, *all* of the applications I work with are multithreading so my situation may be very different from that of some others. > > A reentrant version of ECPG that uses SQLCA and SQLDA like > Oracle or Rdb > > or DB/2 or any of the professional database systems. > > The last time I used Oracle it used SQLCA in a very similar > way as ECPG > does. You are right about Oracle. They use global variables in embedded SQL. (I did not write our company's Oracle driver.) It remains true for all the others that they are multithread capable. It is far better to not make the SQLCA and SQLDA structures global. Since Oracle's model and that of PostgreSQL are very similar (for example in concurrency), it is unsurprising that it might be chosen as a model for implementation of embedded SQL. Let me: 1. Wipe the egg off my face 2. Personally apologize to the entire list and especially to the originators of PostgreSQL's ecpg 3. Restate my opinion in a better way: "PostgreSQL's implementation of embedded SQL is very good. The grammar is complete, it is open source, and highly functional. The licensing is a dream -- useful for any sort of endeavor. There are a couple minor issues that would enhance the functionality of ecpg even more. If the SQLCA were made a local variable to the query, it would be possible to have multiple threads of execution. If PostgreSQL's ecpg were enhanced to have SQLDA structures as specified by "X/Open DR" it would enhance the functionality even further. If such features were added, it would be possible to use ecpg in multithreaded applications, in web servers, in ODBC drivers. In fact, it would become the method of choice for almost any sort of application." I am reminded of Benjamin Franklin, who once said: "You can catch more flies with a teaspoon of sugar than with a gallon of vinegar." ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Non-standard feature request
I know you guys love subject lines like this, but I have a humble
request. Would it be possible to have either a GUC setting or a grammar
change to allow TEMPORARY tables to be dropped at transaction commit? I
know the standard defines the lifetimes of temporary tables to be that
of the session. However, I have CORBA middleware which generates a
transient session object per client. The object connects to the database
at instantiation time and services requests by CORBA's remote method
invocation. Often, the methods invoked on the object cause the object to
create temporary tables. Each method invocation is a single transaction.
But the lifetime of a user's session can be quite long. Worse, CORBA
doesn't permit the application to detect when the client "disconnects" -
the object (and therefore the database connection) remains unless told
explicitly to die. I currently have an evictor pattern remove objects
upon which no method invocation has taken place over a given time. But
in the meantime, dozens of temporary tables have built up. The idea kind
of falls along the same lines as the SET discussion previously. As a
test, it took me about 8 lines of code to implement the change. Of
course, it was a hack, but it worked nicely.
Would a patch to the grammar be accepted? Along the lines of:
CREATE TEMPORARY TABLE
...
ON COMMIT DROP;
pseudo-compatible with the SQL-standard of:
ON COMMIT { DELETE | PRESERVE } ROWS;
so one day PostgreSQL's grammar would look like:
...
ON COMMIT { DROP | { DELETE | PRESERVE } ROWS };
I suppose I could just change the code to query the catalogue for those
temporary tables created during the transaction and issue DROP TABLEs by
hand. But I thought it might be an idea of value to others.
Mike Mascari
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] Making serial survive pg_dump
"Rod Taylor" <[EMAIL PROTECTED]> writes: > Ok, keeping the setval is appropriate. Are there any problems with a > SERIAL() implementation? What for? The sequence name is an implementation detail, not something we want to expose (much less let users modify). regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Making serial survive pg_dump
"Rod Taylor" <[EMAIL PROTECTED]> writes: > Normally I'd agree, but I've found a few people who use normal > sequence operations with serial sequences. That is, they track down > the name and use it. Sure. But what's this have to do with what pg_dump should emit? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Making serial survive pg_dump
Normally I'd agree, but I've found a few people who use normal sequence operations with serial sequences. That is, they track down the name and use it. I'd prefer to force these people to make it manually, but would be surprised if that was a concensus. -- Rod - Original Message - From: "Tom Lane" <[EMAIL PROTECTED]> To: "Rod Taylor" <[EMAIL PROTECTED]> Cc: "Hackers List" <[EMAIL PROTECTED]> Sent: Thursday, June 13, 2002 5:41 PM Subject: Re: [HACKERS] Making serial survive pg_dump > "Rod Taylor" <[EMAIL PROTECTED]> writes: > > Ok, keeping the setval is appropriate. Are there any problems with a > > SERIAL() implementation? > > What for? The sequence name is an implementation detail, not something > we want to expose (much less let users modify). > > 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] Making serial survive pg_dump
-- Rod - Original Message - From: "Tom Lane" <[EMAIL PROTECTED]> To: "Rod Taylor" <[EMAIL PROTECTED]> Cc: "Hackers List" <[EMAIL PROTECTED]> Sent: Thursday, June 13, 2002 9:46 AM Subject: Re: [HACKERS] Making serial survive pg_dump > "Rod Taylor" <[EMAIL PROTECTED]> writes: > > Store sequence information in the SERIAL creation statement: > > CREATE TABLE tab (col1 SERIAL(, )); > > This is wrong because it loses the separation between schema and data. > I do agree that it would be nice if pg_dump recognized serial columns > and dumped them as such --- but the separate setval call is still the > appropriate technique for messing with the sequence contents. We do > not need a syntax extension in CREATE. Ok, keeping the setval is appropriate. Are there any problems with a SERIAL() implementation? ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Making serial survive pg_dump
If we have sequences pick new names automatically, it may not pick the same name after dump / restore as it had earlier -- especially across versions (see TODO entry). So don't we need a way to suggest the *right* name to SERIAL? -- Rod - Original Message - From: "Tom Lane" <[EMAIL PROTECTED]> To: "Rod Taylor" <[EMAIL PROTECTED]> Cc: "Hackers List" <[EMAIL PROTECTED]> Sent: Thursday, June 13, 2002 5:52 PM Subject: Re: [HACKERS] Making serial survive pg_dump > "Rod Taylor" <[EMAIL PROTECTED]> writes: > > Normally I'd agree, but I've found a few people who use normal > > sequence operations with serial sequences. That is, they track down > > the name and use it. > > Sure. But what's this have to do with what pg_dump should emit? > > 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] Making serial survive pg_dump
"Rod Taylor" <[EMAIL PROTECTED]> writes: > If we have sequences pick new names automatically, it may not pick the > same name after dump / restore as it had earlier -- especially across > versions (see TODO entry). > So don't we need a way to suggest the *right* name to SERIAL? No. IMHO, if we change the naming convention for serial sequences (which seems unlikely, except that it might be indirectly affected by changing NAMEDATALEN), then we'd *want* the new naming convention to take effect, not to have pg_dump scripts force an old naming convention to be preserved. I realize there's a potential for failing to restore the setval() information if the name actually does change, but I'm willing to live with that. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Making serial survive pg_dump
Thats fair, and makes the job a heck of a lot simpler. We do need to change the sequence naming once. They have a tendency to conflict at the moment. -- Rod - Original Message - From: "Tom Lane" <[EMAIL PROTECTED]> To: "Rod Taylor" <[EMAIL PROTECTED]> Cc: "Hackers List" <[EMAIL PROTECTED]> Sent: Thursday, June 13, 2002 6:05 PM Subject: Re: [HACKERS] Making serial survive pg_dump > "Rod Taylor" <[EMAIL PROTECTED]> writes: > > If we have sequences pick new names automatically, it may not pick the > > same name after dump / restore as it had earlier -- especially across > > versions (see TODO entry). > > So don't we need a way to suggest the *right* name to SERIAL? > > No. IMHO, if we change the naming convention for serial sequences (which > seems unlikely, except that it might be indirectly affected by changing > NAMEDATALEN), then we'd *want* the new naming convention to take effect, > not to have pg_dump scripts force an old naming convention to be > preserved. > > I realize there's a potential for failing to restore the setval() > information if the name actually does change, but I'm willing to live > with that. > > regards, tom lane > ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] PostGres Doubt
I'm using md5 in pg_hba.conf. That is the method, no? I'm writing a milter application which instantiates a private resource for each thread upon thread startup. I have priv->conn which I establish as priv->conn=PQconnectdb(connstr), connstr is const char *connstr="host=10.0.0.5 dbname=bmilter user=username password=password"; It segfaults depending on it's mood but it tends to happen about 50-70% of the time. I switched to PQsetdbLogin() which has worked perfectly. I don't really want to use that however, I would much prefer using my connstr. Am I missing something? Thanks, David Tom Lane wrote: >David Ford <[EMAIL PROTECTED]> writes: > > >>So reentrancy in libpq basically is put on hold until 7.3. >> >> > >Only if you insist on using "crypt", which is deprecated anyway. >md5 is the preferred encryption method. > >My feeling about the proposed patch was that crypt is now a legacy auth >method, and it's not clear that we should create platform/library >dependencies just to support making multiple connections simultaneously >under crypt auth. (Note that *using* connections concurrently is not >at issue, only whether you can execute the authentication phase of >startup concurrently.) > > 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])
[HACKERS] ATTN: Tom Lane
... while talking to sss.pgh.pa.us.: >> MAIL From:<[EMAIL PROTECTED]> >>> >>> <<< 550 5.7.1 Probable spam from 68.9.71.221 refused - see http://www.five-ten-sg.com/blackhole.php?68.9.71.221 554 5.0.0 Service unavailable Tom, if you block everyone on cable, dialup, dsl, and adsl, then you're probably blocking a lot of legitimate mail. I don't feel like paying some Big Company just so I can relay mail through them when I can do my company's own mail on my own networks. Big Company will get blacklisted soon enough for [inadvertently] allowing a spammer to send mail through them. Please don't punish the victim until they're proven guilty. David p.s. There isn't any contact address on the above URL for the requested updates. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Making serial survive pg_dump
Folks,
> No. IMHO, if we change the naming convention for serial sequences (which
> seems unlikely, except that it might be indirectly affected by changing
> NAMEDATALEN), then we'd *want* the new naming convention to take effect,
> not to have pg_dump scripts force an old naming convention to be
> preserved.
>
> I realize there's a potential for failing to restore the setval()
> information if the name actually does change, but I'm willing to live
> with that.
IMNHO, if this is such a concern for the developer, then what about using
explicitly named sequences? I almost never use the SERIAL data type, because
I feel that I need naming control as well as explicit permissions. SERIAL is
a convenience for those who don't want to be bothered ... serious developers
hould use DEFAULT NEXTVAL('sequence_name').
--
-Josh Berkus
---(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] First cut at SSL documentation
Sorry, there is a newer version. I will use that one. --- Bear Giles wrote: > Attached is the first cut at some SSL documetation for the > PostgreSQL manual. It's in plain text, not DocBook, to make > editing easy for the first few revisions. The documentation > leads the code by a day or so. > > Also, I'm still having problems with the patches list - none > of my recent submissions have gotten through, and I haven't > even gotten the confirmation note from when I tried to resubscribe > to that list. That's why the main SSL patches haven't appeared yet. > > Bear Content-Description: /tmp/ssldoc [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org -- 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] ATTN: Tom Lane
David Ford <[EMAIL PROTECTED]> writes: > Tom, if you block everyone on cable, dialup, dsl, and adsl, then you're probably >blocking a lot of legitimate mail. David, let me explain this in words of one syllable: I am currently rejecting upwards of 2000 spam messages per day. If I did not have extremely stringent filters in place, email would be completely useless to me. Advice suggesting that I weaken my filters will be ignored with as much grace as I can muster, which on most days is not a lot. This is what comes of having several well-publicized email addresses :-( regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] First cut at SSL documentation
Your patch has been added to the PostgreSQL unapplied patches list at: http://candle.pha.pa.us/cgi-bin/pgpatches I will try to apply it within the next 48 hours. --- Bear Giles wrote: > Attached is the first cut at some SSL documetation for the > PostgreSQL manual. It's in plain text, not DocBook, to make > editing easy for the first few revisions. The documentation > leads the code by a day or so. > > Also, I'm still having problems with the patches list - none > of my recent submissions have gotten through, and I haven't > even gotten the confirmation note from when I tried to resubscribe > to that list. That's why the main SSL patches haven't appeared yet. > > Bear Content-Description: /tmp/ssldoc [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org -- 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] PostGres Doubt
David Ford <[EMAIL PROTECTED]> writes: > I'm using md5 in pg_hba.conf. That is the method, no? > I'm writing a milter application which instantiates a private resource > for each thread upon thread startup. I have priv->conn which I > establish as priv->conn=PQconnectdb(connstr), connstr is const char > *connstr="host=10.0.0.5 dbname=bmilter user=username password=password"; > It segfaults depending on it's mood but it tends to happen about 50-70% > of the time. Could you dig out ye olde gdb and figure out *why* it's segfaulting? At the very least, give us a stack backtrace from a debug-enabled build. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] Chinese GB18030 support is implemented!
> Great!Thanks for your help. You are welcome. > Would you please update the Makefile under Unicode?it should be updated > for GB18030. done. -- Tatsuo Ishii ---(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] First cut at SSL documentation
> Sorry, there is a newer version. I will use that one. You may want to hold off on that - I've been busy lately and haven't had a chance to revisit the documentation or change some of the literal constants to numeric constants, but it's been on my "to do" list. The latter didn't affect the other patches since I planned on doing a latter-day patch anyway, but the documentation may need some big changes to emphasize that the rule that it's "use SSH tunnels if you just want to prevent eavesdropping, use SSL directly if you need to firmly establish the identity of the server or clients." (And sorry about responding via the lists, but your mail server doesn't like to talk to cable modem users.) Bear ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Making serial survive pg_dump
> Currently serial is dumped as a sequence and appropriate default > statement. > > With my upcoming dependency patch serials depend on the appropriate > column. Drop the column (or table) and the sequence goes with it. > The depencency information does not survive the pg_dump / restore > process however as it's recreated as the table and individual > sequence. What happens is the sequence is shared between several tables (eg. invoice numbers or something) Chris ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Making serial survive pg_dump
> What happens is the sequence is shared between several tables (eg. invoice > numbers or something) You cannot accomplish this situation by strictly using the SERIAL type. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] First cut at SSL documentation
Bear Giles wrote: > > Sorry, there is a newer version. I will use that one. > > You may want to hold off on that - I've been busy lately and haven't had > a chance to revisit the documentation or change some of the literal constants > to numeric constants, but it's been on my "to do" list. OK, thanks. I will hold off on the docs part. Sorry it has taken me so long to get to these SSL patches (my vacation). I am doing them now. > The latter didn't affect the other patches since I planned on doing a > latter-day patch anyway, but the documentation may need some big changes > to emphasize that the rule that it's "use SSH tunnels if you just want > to prevent eavesdropping, use SSL directly if you need to firmly establish > the identity of the server or clients." > > (And sorry about responding via the lists, but your mail server doesn't > like to talk to cable modem users.) Sorry about the block. RBL+ has been much more effective lately, and it is because they are blocking more dialup users. This the first false positive I have gotten from them. You can use [EMAIL PROTECTED] or route your email through west.navpoint.com. I will see if I can pass your IP through. I can do it in my blacklist, but I am not sure that works for RBL+. -- 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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] PostGres Doubt
David Ford wrote: > I'm using md5 in pg_hba.conf. That is the method, no? > > I'm writing a milter application which instantiates a private resource > for each thread upon thread startup. I have priv->conn which I > establish as priv->conn=PQconnectdb(connstr), connstr is const char > *connstr="host=10.0.0.5 dbname=bmilter user=username password=password"; > > It segfaults depending on it's mood but it tends to happen about 50-70% > of the time. I switched to PQsetdbLogin() which has worked perfectly. > I don't really want to use that however, I would much prefer using my > connstr. Wow, I am confused. md5 should be fine. Certainly sounds like there is a thread problem with PQconnectdb(). Are you using 7.2.X? -- 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] First cut at SSL documentation
* Bruce Momjian <[EMAIL PROTECTED]> [020613 21:49]: > Bear Giles wrote: > > > Sorry, there is a newer version. I will use that one. > > > > You may want to hold off on that - I've been busy lately and haven't had > > a chance to revisit the documentation or change some of the literal constants > > to numeric constants, but it's been on my "to do" list. > > OK, thanks. I will hold off on the docs part. > > Sorry it has taken me so long to get to these SSL patches (my vacation). > I am doing them now. > > > The latter didn't affect the other patches since I planned on doing a > > latter-day patch anyway, but the documentation may need some big changes > > to emphasize that the rule that it's "use SSH tunnels if you just want > > to prevent eavesdropping, use SSL directly if you need to firmly establish > > the identity of the server or clients." > > > > (And sorry about responding via the lists, but your mail server doesn't > > like to talk to cable modem users.) > > Sorry about the block. RBL+ has been much more effective lately, and it > is because they are blocking more dialup users. This the first false > positive I have gotten from them. You can use [EMAIL PROTECTED] or > route your email through west.navpoint.com. I will see if I can pass > your IP through. I can do it in my blacklist, but I am not sure that > works for RBL+. If you are using sendmail, the access file overrides the RBL, if you set delay checks in the MC file. I can help if you are using sendmail. LER > > -- > 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 6: Have you searched our list archives? > > http://archives.postgresql.org > -- 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] Making serial survive pg_dump
"Rod Taylor" <[EMAIL PROTECTED]> writes: >> What happens is the sequence is shared between several tables (eg. >> invoice numbers or something) > You cannot accomplish this situation by strictly using the SERIAL > type. But Chris is correct that there are borderline cases where we might do the wrong thing if we're not careful. The real question here, I suspect, is what rules pg_dump will use to decide that it ought to suppress a CREATE SEQUENCE command, DEFAULT clause, etc, in favor of emitting a SERIAL column datatype. In particular, ought it to depend on looking at the form of the name of the sequence? I can see arguments both ways on that... regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] First cut at SSL documentation
Larry Rosenman wrote: > > Sorry about the block. RBL+ has been much more effective lately, and it > > is because they are blocking more dialup users. This the first false > > positive I have gotten from them. You can use [EMAIL PROTECTED] or > > route your email through west.navpoint.com. I will see if I can pass > > your IP through. I can do it in my blacklist, but I am not sure that > > works for RBL+. > If you are using sendmail, the access file overrides the RBL, if you > set delay checks in the MC file. > > I can help if you are using sendmail. Yes, using sendmail. That is helpful info. I don't have delay checks enabled right now, but can easily do that. Thanks. -- 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 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] First cut at SSL documentation
Larry Rosenman wrote: > > Sorry about the block. RBL+ has been much more effective lately, and it > > is because they are blocking more dialup users. This the first false > > positive I have gotten from them. You can use [EMAIL PROTECTED] or > > route your email through west.navpoint.com. I will see if I can pass > > your IP through. I can do it in my blacklist, but I am not sure that > > works for RBL+. > If you are using sendmail, the access file overrides the RBL, if you > set delay checks in the MC file. > > I can help if you are using sendmail. OK, Bear, configured for 192.168.1.3. Would you shoot me a personal email as a test? Send failure message to [EMAIL PROTECTED] Thanks. -- 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] Making serial survive pg_dump
Tom Lane wrote: > "Rod Taylor" <[EMAIL PROTECTED]> writes: > >>>What happens is the sequence is shared between several tables (eg. >>>invoice numbers or something) >> > >>You cannot accomplish this situation by strictly using the SERIAL >>type. > > > But Chris is correct that there are borderline cases where we might > do the wrong thing if we're not careful. The real question here, > I suspect, is what rules pg_dump will use to decide that it ought > to suppress a CREATE SEQUENCE command, DEFAULT clause, etc, in > favor of emitting a SERIAL column datatype. In particular, ought it > to depend on looking at the form of the name of the sequence? > I can see arguments both ways on that... > I think that when SERIAL is used, the sequence should be tied inextricably to the table which created it, and it should be hidden from use for other purposes (perhaps similar to the way a toast table is). If you *want* to use a sequence across several tables, then you don't use SERIAL, you create a sequence. Many people who come from an MS SQL Server background are used to an IDENTITY column being tied transparently to the table in this fashion, and they initially find sequences confusing. Conversely, people coming from an Oracle background are quite comfortable with sequences, and don't understand why it is necessary to have an IDENTITY type column at all -- they seem too restrictive. We have people from both backgrounds where I work, and both databases in use for various applications, and this is at least what I have observed. This is a chance for PostgreSQL to support people from both camps equally well. Anyway, just my 2c :-) Joe ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Making serial survive pg_dump
> I think that when SERIAL is used, the sequence should be tied > inextricably to the table which created it, and it should be hidden from > use for other purposes (perhaps similar to the way a toast table is). If > you *want* to use a sequence across several tables, then you don't use > SERIAL, you create a sequence. Agreed. Maybe an extra column in pg_attribute or something? Chris ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: Default privileges for new databases (was Re: [HACKERS] Can't import
Josh Berkus wrote: > > Tom, > > > Probably we should have temp table creation allowed to all by default. > > I'm not convinced that that's a good idea for schema-creation privilege > > though. Related issues: what should initdb set as the permissions for > > template1? Would it make sense for newly created databases to copy > > their permission settings from the template database? (Probably not, > > since the owner is likely to be different.) What about copying those > > per-database config settings Peter just invented? > > Yes. I think there should be a not optional INITDB switch: either --secure > or --permissive. People usually know at the time of installation whether > they're building a web server (secure) or a home workstation (permissive). > > Depending on the setting, this should set either a grant all or revoke all for > non-db owners as default, including such things as temp table creation. I like this idea. I think we should prompt for tcp socket permission setting for only the owner (Peter E's idea that I think he wants for 7.3), default public schema permissions, temp shema permissions, stuff like that. We can have initdb flags to prevent the prompting, but doing this quering at initdb time seems like an ideal solution. We have needed such control for a while. -- 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] Non-standard feature request
Mike Mascari <[EMAIL PROTECTED]> writes: > ... Would it be possible to have either a GUC setting or a grammar > change to allow TEMPORARY tables to be dropped at transaction commit? This seems like a not unreasonable idea; but the lack of other responses suggests that the market for such a feature isn't there. Perhaps you should try to drum up some interest on pgsql-general and/or pgsql-sql. 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])
