Re: [GENERAL] possible psql \d bug in 8.3 beta2
--- On Sun, 12/23/07, Tom Lane <[EMAIL PROTECTED]> wrote: > > -+-+---+-- > > project | managers| table | teaminst > > It's hidden by the "managers" table in the > earlier "history" schema. > \d without any particular schema specification will > only show tables > that could be accessed by an unqualified table name. I see. Thanks for the clarification. Regards, Richard Broersma Jr. ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [GENERAL] possible psql \d bug in 8.3 beta2
Richard Broersma Jr <[EMAIL PROTECTED]> writes: > Is seems that \d is missing the following entry > when I set search_path to display two schemas: > List of relations > Schema |Name | Type | Owner > -+-+---+-- > project | managers| table | teaminst It's hidden by the "managers" table in the earlier "history" schema. \d without any particular schema specification will only show tables that could be accessed by an unqualified table name. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
[GENERAL] possible psql \d bug in 8.3 beta2
Is seems that \d is missing the following entry when I set search_path to display two schemas: List of relations Schema |Name | Type | Owner -+-+---+-- project | managers| table | teaminst instrumentation=> select version(); version PostgreSQL 8.3beta2, compiled by Visual C++ build 1400 (1 row) instrumentation=> set search_path to project; SET instrumentation=> \d List of relations Schema |Name | Type | Owner -+-+---+-- project | managers| table | teaminst project | project_tls | table | teaminst project | projects| table | teaminst (3 rows) instrumentation=> set search_path to history; SET instrumentation=> \d List of relations Schema | Name | Type | Owner -+--+---+-- history | managers | table | teaminst (1 row) instrumentation=> set search_path to history, project; SET instrumentation=> \d List of relations Schema |Name | Type | Owner -+-+---+-- history | managers| table | teaminst <--where is project.managers project | project_tls | table | teaminst project | projects| table | teaminst (3 rows) instrumentation=> Regards, Richard Broersma Jr. ---(end of broadcast)--- TIP 1: 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: [GENERAL] Constraint Trigger's referenced_table
--- On Sun, 12/23/07, Tom Lane <[EMAIL PROTECTED]> wrote: > (and, depending on which trigger you are talking about, perhaps > make it hold by changing the other table). Okay, I take it that changing the other table would only apply to tables that were designed with foreign key constraints that have ON UPDATE or ON DELETE actions set. I think I understand now. Thanks for the clarification. Regards, Richard Broersma JR. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [GENERAL] pgsql cannot read utf8 files moved from windows correctly!
On 12/23/00, Martin Gainty <[EMAIL PROTECTED]> wrote: > the specifics.. > > Some byte oriented protocols expect ASCII characters at the beginning of a > file. > If UTF-8 is used with these protocols, use of the BOM as encoding form > signature should be avoided. Sure, but that isn't true of generic text files, which is one of the major applications of a UTF-8 BOM. Especially when said text files are being fed to something that understands multiple encodings. The other items on that page say as much... ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [GENERAL] pgsql cannot read utf8 files moved from windows correctly!
the specifics.. Some byte oriented protocols expect ASCII characters at the beginning of a file. If UTF-8 is used with these protocols, use of the BOM as encoding form signature should be avoided. M-- - Original Message - From: "Trevor Talbot" <[EMAIL PROTECTED]> To: Sent: Sunday, December 23, 2007 1:55 PM Subject: Re: [GENERAL] pgsql cannot read utf8 files moved from windows correctly! > On 12/23/07, Martin Gainty <[EMAIL PROTECTED]> wrote: > > > it seems the use of BOM in UTF-8 is discouraged > > http://unicode.org/faq/utf_bom.html#BOM > > Where do you see it being discouraged? > > ---(end of broadcast)--- > TIP 6: explain analyze is your friend > ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [GENERAL] Constraint Trigger's referenced_table
Richard Broersma Jr <[EMAIL PROTECTED]> writes: > --- On Sat, 12/22/07, Tom Lane <[EMAIL PROTECTED]> wrote: >> No, the purpose is to support foreign-key triggers. FK constraints are >> implemented via cooperating triggers on the two tables, and >> each trigger has to be able to look at the other table. > When you say "each trigger has to be able to look" do you mean that each > trigger needs to be notified when other table has records that are > inserted/updated/deleted? No, each trigger fires for events in its own table. It then has to go look at the other table to see if the FK constraint holds (and, depending on which trigger you are talking about, perhaps make it hold by changing the other table). regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [GENERAL] postgres UTC different from perl?
Louis-David Mitterrand <[EMAIL PROTECTED]> writes: > On Wed, Dec 19, 2007 at 08:14:17PM -0500, Tom Lane wrote: >> Richard Huxton <[EMAIL PROTECTED]> writes: >>> I'm not sure that (CURRENT_DATE AT TIME ZONE 'UTC') does what you think >>> it does. Try setting your timezone to various offsets and exploring. > Does that mean it's a postgresql bug? No. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [GENERAL] pgsql cannot read utf8 files moved from windows correctly!
On 12/23/07, Martin Gainty <[EMAIL PROTECTED]> wrote: > it seems the use of BOM in UTF-8 is discouraged > http://unicode.org/faq/utf_bom.html#BOM Where do you see it being discouraged? ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [GENERAL] pgsql cannot read utf8 files moved from windows correctly!
bookman bookman wrote: H i, I copied a table in sqlserver2005 to a txt file(There were many chinese words in it).I saved it as a file encoded by ANSI,but I cant open it in ubuntu.I tried GBK,GB18030, UTF8,It just could not be opened. Then I save it in windows with encoding UTF8,then I can open it in ubuntu.I copied it to postgresql,but the file could not be read correctly.For example,here is a file: --book.txt bookid(int) bookname(varchar(30)) 1 Java I created a table "book" in postgre,then I input the command line: copy book from '/home/postgres/data/book.txt' The error was: error:invalid input syntax for integer:" 1"; context:line 1,column bookid I know that every line of utf8 files is started with "fffe" or "feff" and ended with "\r\n" in windows but not in linux,so the character "1" has a space before it in the error line. Not long ago i ran into a similar problem with UTF-8 and BOM. It turned out that a client of mine had edited some files in an old version of Homesite for Windows, which has a bit of an issue in this area: http://kb.adobe.com/selfservice/viewContent.do?externalId=tn_19059&sliceId=1 Perhaps yours is a related problem? brian ---(end of broadcast)--- TIP 1: 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: [GENERAL] postgres UTC different from perl?
On Wed, Dec 19, 2007 at 08:14:17PM -0500, Tom Lane wrote:
> Richard Huxton <[EMAIL PROTECTED]> writes:
> > I'm not sure that (CURRENT_DATE AT TIME ZONE 'UTC') does what you think
> > it does. Try setting your timezone to various offsets and exploring.
>
> In fact, I think it's adjusting in exactly the wrong direction.
>
> I get the right number from
>
> regression=# select date_part('epoch', 'today'::timestamp at time zone 'UTC');
> date_part
>
> 1198022400
> (1 row)
>
> and the wrong one from
>
> regression=# select date_part('epoch', 'today'::timestamptz at time zone
> 'UTC');
> date_part
>
> 1198058400
> (1 row)
>
> and I think the locution with CURRENT_DATE is equivalent to the second
> case because timestamptz is the preferred type to promote date to.
Does that mean it's a postgresql bug?
---(end of broadcast)---
TIP 6: explain analyze is your friend
Re: [GENERAL] pgsql cannot read utf8 files moved from windows correctly!
it seems the use of BOM in UTF-8 is discouraged http://unicode.org/faq/utf_bom.html#BOM FF FE is UTF16-Little Endian FE FF is UTF16-Big Endian Please verify- Bedankt/ Martin- - Original Message - From: "Trevor Talbot" <[EMAIL PROTECTED]> To: Sent: Sunday, December 23, 2007 10:39 AM Subject: Re: [GENERAL] pgsql cannot read utf8 files moved from windows correctly! > On 12/20/07, Martijn van Oosterhout <[EMAIL PROTECTED]> wrote: > > On Tue, Dec 18, 2007 at 02:53:16PM +0800, bookman bookman wrote: > > > > I know that every line of utf8 files is started with "fffe" or "feff" > > > and ended with "\r\n" in windows but not in linux,so the character > > > "1" has a space before it in the error line. > > > Err, no. In UTF-16 files it is common to begin the *file* with that > > character, but UTF-8 doesn't have that character anywhere, it's > > illegal. Just stripping them out should be fine. > > A BOM is perfectly legal in UTF-8, and it's commonly used as a > signature to indicate the text is UTF-8 instead of another encoding. > But yes, it is at the beginning of the file only. > > http://unicode.org/faq/utf_bom.html#29 > > ---(end of broadcast)--- > TIP 4: Have you searched our list archives? > >http://archives.postgresql.org/ > ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [GENERAL] pgsql cannot read utf8 files moved from windows correctly!
On 12/20/07, Martijn van Oosterhout <[EMAIL PROTECTED]> wrote: > On Tue, Dec 18, 2007 at 02:53:16PM +0800, bookman bookman wrote: > > I know that every line of utf8 files is started with "fffe" or "feff" > > and ended with "\r\n" in windows but not in linux,so the character > > "1" has a space before it in the error line. > Err, no. In UTF-16 files it is common to begin the *file* with that > character, but UTF-8 doesn't have that character anywhere, it's > illegal. Just stripping them out should be fine. A BOM is perfectly legal in UTF-8, and it's commonly used as a signature to indicate the text is UTF-8 instead of another encoding. But yes, it is at the beginning of the file only. http://unicode.org/faq/utf_bom.html#29 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org/
Re: [GENERAL] update pg question?
On Thu, Dec 20, 2007 at 11:48:08PM -0800, ivan.hou wrote: > > how to update the pg version 8.1.3 to 8.1.10? should i backup and drop my > database , or delete the /usr/local/pgsql directory? Just install it. Upgrades involving only the third number (the "minor" revision) don't require any changes to data files. Have a nice day, -- Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/ > Those who make peaceful revolution impossible will make violent revolution > inevitable. > -- John F Kennedy signature.asc Description: Digital signature
Re: [GENERAL] Constraint Trigger's referenced_table
--- On Sat, 12/22/07, Tom Lane <[EMAIL PROTECTED]> wrote: > No, the purpose is to support foreign-key triggers. FK constraints are > implemented via cooperating triggers on the two tables, and > each trigger has to be able to look at the other table. When you say "each trigger has to be able to look" do you mean that each trigger needs to be notified when other table has records that are inserted/updated/deleted? >From what I gathered from the reading of ri_triggers.c, FWIU it seems that >this kind of cross table checking is designed to seek out any FKs or PKs in >the related table and then execute a validating query that compares the PK to >FK. Can this kind of cross checking still be implemented for temporal relations where foreign keys are not actually implemented in the "referencing" table. For example I want to enforce the primary-relation's time range to always engulf the time range of the foreign-relation.: PK timeline: |---p1---|--p2--|-p3-|p4|---p5---| FK timeline: |-f1-|f2|--f3--|--f4--| So if I INSERT/UPDATE/DELETE records to either table, would implementing the "FROM referenced_table" predicated of the CREATE Constraint Trigger enable this kind of notification to perform cross checking even though there are strictly no pk/fk relations between these table? Regards, Richard Broersma Jr. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
