Re: [GENERAL] PostgreSQL index issue
mperformer wrote: > I have a question regarding PostgreSQL 9.1 indexing. > > I am having a table and want to create a index for a column and I want to store the data with time > zone for that column. The questions are: > > 1. Can I create a index for a column which store time stamp with time zone. If can is there ant > performance issues? Yes, you can create an index on a TIMESTAMP WITH TIME ZONE column. There are no performance problems except the ones that always come with an index: INSERTs, UPDATEs and DELETEs will be slower and do more disk I/O and locking. > 2. Also I can store the time stamp value with zone as a long integer value. If so what is the > difference between the above step. Which one is better. The smaller the indexed column is, the smaller and faster the index will be. A timestamp uses 8 bytes, same as a bigint, so that shouldn't matter. Use the representation that is most useful to your processing. For timestamps, this is usually the timestamp data type (which automatically rejects impossible dates and provides date arithmetic). Yours, Laurenz Albe -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] PostgreSQL limitations question
On 07/12/2012 02:16 PM, Bartosz Dmytrak wrote: it doesn't metter - conclusion is: table is growing. You are right, for other purposes it should be better to check total size. In that case, I'm not sure I understand what you were actually asking in your initial question. -- Craig Ringer
[GENERAL] Full text search advice requested
I have a table with bibliometric information on published articles. Fields of interest for full text searches are the 'title' and 'abstract' fields. Those fields can contain several languages but most of the entries use English. A grouped query on the 'language' field reveals that the following languages are involved: Afrikaans Chinese Dutch English French Gaelic (?) German Hungarian Italian Japanese Korean Polish Portuguese Rumanian Russian Slovene Sotho Spanish Turkish Xhosa Zulu Now my questions: 1. Is it possible at all to use full text search in such a setup? 2. If so, how would I approach the different languages in indexing and querying. 3. How do I ask postgresql which dictionaries are already available in the installation for full text search? 4. If full text searches cannot be utilised in such a setup, can trgm-related indexing using 'similarity' be a replacement? I think not. Regards Johann -- Johann SpiesTelefoon: 021-808 4699 Databestuurder / Data manager Sentrum vir Navorsing oor Evaluasie, Wetenskap en Tegnologie Centre for Research on Evaluation, Science and Technology Universiteit Stellenbosch. "Delight thyself also in the LORD: and he shall give thee the desires of thine heart." Psalms 37:4 E-pos vrywaringsklousule Hierdie e-pos mag vertroulike inligting bevat en mag regtens geprivilegeerd wees en is slegs bedoel vir die persoon aan wie dit geadresseer is. Indien u nie die bedoelde ontvanger is nie, word u hiermee in kennis gestel dat u hierdie dokument geensins mag gebruik, versprei of kopieer nie. Stel ook asseblief die sender onmiddellik per telefoon in kennis en vee die e-pos uit. Die Universiteit aanvaar nie aanspreeklikheid vir enige skade, verlies of uitgawe wat voortspruit uit hierdie e-pos en/of die oopmaak van enige lês aangeheg by hierdie e-pos nie. E-mail disclaimer This e-mail may contain confidential information and may be legally privileged and is intended only for the person to whom it is addressed. If you are not the intended recipient, you are notified that you may not use, distribute or copy this document in any manner whatsoever. Kindly also notify the sender immediately by telephone, and delete the e-mail. The University does not accept liability for any damage, loss or expense arising from this e-mail and/or accessing any files attached to this e-mail. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] question about installation
On Wed, Jul 11, 2012 at 6:28 PM, martin soethof wrote: > Hello > I have the following situation. > I used a postgres installer that can choose seperate paths for the normal > postgres and the data folder. > I used this because i wanted to share a database on an external hard drive > between 2 computers. > I installed it on PC #1, the normal postgres files are on my D drive, the > data folder and its components are on the portable F drive.. > Tomorrow i will be sitting behind PC #2, how should i install it.. > If i do install it the same way, won't that overwrite the existing data > folder on the F drive and thus result in loss of data or a corrupt database. > Or will postgres-installation simply notice i already have a data folder > there and ask if i want to share this? > Could you please guide me through the path of how to install postgresql on > the 2nd computer, so that both computers share their data in the same > folder.. > I used postgresql 8.4 > The installer will not over-write any settings in your data folder and continue as usual. Its an option where you can give a pre-existing data folder to a new installation. > Regards, > Martin > -- Regards, Sachin Srivastava EnterpriseDB, India
Re: [GENERAL] PostgreSQL limitations question
On 07/12/2012 12:39 AM, Craig Ringer wrote: On 07/12/2012 02:16 PM, Bartosz Dmytrak wrote: it doesn't metter - conclusion is: table is growing. You are right, for other purposes it should be better to check total size. In that case, I'm not sure I understand what you were actually asking in your initial question. I understood it to be asking about the conflict between the two statements below: Maximum Table Size 32 TB Maximum Rows per Table Unlimited If a table has a maximum size and rows have size then at some point you will reach a limit on number of rows per table. -- Craig Ringer -- Adrian Klaver adrian.kla...@gmail.com -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Pg CRUD for joined tables
> I'm looking for FOSS PostgreSQL CRUD software, preferably > Perl-compatible, which will enable me to design input forms which can > handle input to tables which reference other tables by foreign key. > Most CRUD applications I have seen so far only deal with direct, form > field to table field input but I want to build forms which have the > same fields as a VIEW derived from multiple table joins. In other > words, I want the CRUD to handle the the joins. > > Any suggestions? Not for Perl, but Python: SQLalchemy. An ORM that allows you to have (nearly) arbitrarily complex mappings between your object model and the database tables. GUI frameworks that use SQlalchemy are: Sqlkit, Pypapi, Camelot, Qtalchemy. Sincerely, Wolfgang -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] PostgreSQL limitations question
Adrian Klaver writes: > On 07/12/2012 12:39 AM, Craig Ringer wrote: >> In that case, I'm not sure I understand what you were actually asking in >> your initial question. > I understood it to be asking about the conflict between the two > statements below: > Maximum Table Size32 TB > Maximum Rows per TableUnlimited > If a table has a maximum size and rows have size then at some point you > will reach a limit on number of rows per table. I think the "unlimited" should be read as "you'll hit some other limit first". For example, I trust no one would read that line as implying that we can store more data than will fit on the machine's disks. In the same way, it's not meant to suggest that the number of rows isn't effectively limited by the max table size. We could perhaps replace "unlimited" by the result of dividing the max table size by the minimum row size. I'm not sure that would be particularly helpful though, since most tables are probably a good deal wider than the minimum row size, and so the effective limit would be quite a bit less. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] PostgreSQL limitations question
On 07/12/2012 06:44 AM, Tom Lane wrote: Adrian Klaver writes: On 07/12/2012 12:39 AM, Craig Ringer wrote: In that case, I'm not sure I understand what you were actually asking in your initial question. I understood it to be asking about the conflict between the two statements below: Maximum Table Size 32 TB Maximum Rows per Table Unlimited If a table has a maximum size and rows have size then at some point you will reach a limit on number of rows per table. I think the "unlimited" should be read as "you'll hit some other limit first". For example, I trust no one would read that line as implying that we can store more data than will fit on the machine's disks. In the same way, it's not meant to suggest that the number of rows isn't effectively limited by the max table size. I would agree, but the OPs question was: " My question is: how is it possible to *reach* unlimited rows in table? " We could perhaps replace "unlimited" by the result of dividing the max table size by the minimum row size. I'm not sure that would be particularly helpful though, since most tables are probably a good deal wider than the minimum row size, and so the effective limit would be quite a bit less. regards, tom lane -- Adrian Klaver adrian.kla...@gmail.com -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] PostgreSQL limitations question
On Jul 12, 2012, at 9:44, Tom Lane wrote: > > We could perhaps replace "unlimited" by the result of dividing the max > table size by the minimum row size. I'm not sure that would be > particularly helpful though, since most tables are probably a good deal > wider than the minimum row size, and so the effective limit would be > quite a bit less. > > regards, tom lane > How about saying: "No Fixed Limit - see Table Size" There is a semantic difference between being limited by the file-system (thus internally unlimited) or being limited by an internal constraint (table size). Pointing out the implication that a maximum table size necessarily limits the maximum number of rows stored benefits a very small fraction of the audience but it doesn't cause any harm to the remainder and doesn't cost much to implement. You could also provide a range: 20 to millions+; based on the max row size of 1.2TB and whatever the minimum size would result in. David J. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] ERROR: out of shared memory - But the table is empty
Hi there, not being an expert for Postgres…. I have a Postgis table with the countries of the world. Now, I would like to drop it. I got the error message: ERROR: out of shared memory HINT: You might need to increase max_locks_per_transaction. and thought that it would be easier to drop first all rows, and then drop the empty table. But it seems that it has a problem with dropping the index: DROP INDEX gis.countries_uid; actually generates that error message. So, do I need to dig now into the postgres config file? It seems strange to me that Postgres has a problem deleting an empty table, though. Thanks for any hints. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Python + listen/notify
Hei Josh, problem solved! Thanks for your help! On Wed, Jul 11, 2012 at 4:27 PM, Josh Kupershmidt wrote: > [Please keep the list CC'd] > > On Wed, Jul 11, 2012 at 3:58 AM, Filipe brandão > wrote: > > > Now, i only need to link these processes (trigger completion and running > the > > script). > > How can i do it with Listen / Notify? Issue a notify in the end of the > > trigger and a listen on the python script? > > Yes, that should work fine. See the doc pages for LISTEN and NOTIFY: > http://www.postgresql.org/docs/current/static/sql-listen.html > http://www.postgresql.org/docs/current/static/sql-notify.html > > Along with the link I sent earlier to the psycopg2 section, assuming > you are in fact using psycopg2 as your database connector. I suggest > trying out the psycopg2 example in their docs verbatim first, then > adapting the example to your own code. > -- Filipe Brandão
Re: [GENERAL] installation problem with postgres password
postgres user does not exist yet, its a fresh new installation of windows 7 Home. New HP laptop. there is only my account (admin) and Guest i saw on internet someone had similar problem and this was resolved by removing HP protection tools tha was messing with policies, but i already removed it before. On Thu, Jul 12, 2012 at 8:02 AM, raghu ram wrote: > > > On Thu, Jul 12, 2012 at 8:35 AM, KOTa wrote: >> >> that is what i though, but i tried many different combinations for >> password, and at least 1 of them should satisfy policy requirements. >> also my windows user password, which is accepted by OS and thus >> satisfies the requirements resulted in same message >> >> i did try to see what policy is active, but i am using win 7 Home >> Premium and i could find a way for this version to see/change >> policies. >> the only thing i found is by running "net accounts" from command >> prompt. which shows the following: >> >> http://gyazo.com/be1089b5f0a1ebe6b8037ad9322eac31.png?1342061599 >> >> and those are very simple password policy which all combinations i used >> satisfy > > > Could you please try to reset the "postgres" user password in window7 before > reinstalling the PostgreSQL. Below link gives more information of reseting > password in windows7 > > http://pcsupport.about.com/od/windows7/ht/change-password-windows-7.htm > > Thanks & Regards, > > Raghu Ram > > EnterpriseDB Corporation > > Blog:http://raghurc.blogspot.in/ > > > -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Bug? Prepared queries continue to use search_path from their preparation time
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 >> This behavior is intentional. > In that case, the error lies with the Perl libraries that automatically > prepare and cache queries, but do not include the search_path in the > cache keys. You have lost me there. Which Perl libraries are those? - -- Greg Sabino Mullane g...@turnstep.com End Point Corporation http://www.endpoint.com/ PGP Key: 0x14964AC8 201207121257 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iEYEAREDAAYFAk//AlQACgkQvJuQZxSWSsj6IACgzQJlK5Y1u1Pr3KDyR6ax3Elb 4ycAoOPo5XJn0Uxx7Lvg30u3iCBoibp6 =oKaV -END PGP SIGNATURE- -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] PostgreSQL limitations question
2012/7/12 David Johnston > > > How about saying: "No Fixed Limit - see Table Size" > > I am sorry for delay. My intention was to start discussion about unlimited number of rows. I like this idea: "No Fixed Limit - see Table Size" Another, maybe only academic, discussion is about maximum number of indexes per table. Reason is the same. Indexes are stored in table pg_class (relkind = 'i'), so when we agree number of table rows is limited, then number of indexes is limited too. There is fair sentence for number of columns - "depending on column type". I think there should be an explanation what *unlimited* really means. Thanks for Your attention. Regards, Bartek
[GENERAL] how much volatile is a function
I have a table, this table are rarely changed (added or deleted). My function receive parameters and do a query to the table. Does postgres re run the query on each function call, or has some kind of "flag" indicating that table as not been changed and return cached result of a previous call if the call has same parameters? Thanks!
Re: [GENERAL] how much volatile is a function
From: pgsql-general-ow...@postgresql.org [mailto:pgsql-general-ow...@postgresql.org] On Behalf Of Anibal David Acosta Sent: Thursday, July 12, 2012 2:39 PM To: pgsql-general@postgresql.org Subject: [GENERAL] how much volatile is a function I have a table, this table are rarely changed (added or deleted). My function receive parameters and do a query to the table. Does postgres re run the query on each function call, or has some kind of "flag" indicating that table as not been changed and return cached result of a previous call if the call has same parameters? Thanks! == See here: http://www.postgresql.org/docs/9.1/interactive/sql-createfunction.html Read the difference between IMMUTABLE, STABLE, and VOLATILE David J. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] how much volatile is a function
On Thu, Jul 12, 2012 at 10:38 PM, Anibal David Acosta wrote: > Does postgres re run the query on each function call, or has some kind of > “flag” indicating that table as not been changed and return cached result of > a previous call if the call has same parameters? It does re-run it on each call. -- Sergey Konoplev a database architect, software developer at PostgreSQL-Consulting.com http://www.postgresql-consulting.com Jabber: gray...@gmail.com Skype: gray-hemp Phone: +79160686204 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] how much volatile is a function
On Thu, Jul 12, 2012 at 10:55 PM, Sergey Konoplev wrote: > On Thu, Jul 12, 2012 at 10:38 PM, Anibal David Acosta > wrote: >> Does postgres re run the query on each function call, or has some kind of >> “flag” indicating that table as not been changed and return cached result of >> a previous call if the call has same parameters? > > It does re-run it on each call. ps. Do not get confused with IMMUTABLE, STABLE and VOLATILE flags. It is kind of promising to the planner that the function will behave like specified. > > -- > Sergey Konoplev > > a database architect, software developer at PostgreSQL-Consulting.com > http://www.postgresql-consulting.com > > Jabber: gray...@gmail.com Skype: gray-hemp Phone: +79160686204 -- Sergey Konoplev a database architect, software developer at PostgreSQL-Consulting.com http://www.postgresql-consulting.com Jabber: gray...@gmail.com Skype: gray-hemp Phone: +79160686204 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Output of query_to_xml
On tor, 2012-06-21 at 07:49 +0200, P. Broennimann wrote:
> select query_to_xml('select * from table12', true, true, '') into ...
> The result is OK but there is always an empty line:
>
> http://www.w3.org/2001/XMLSchema-instance";>
> *<-- Empty line here*
> FG8976SDFRETG
> NL
> 2011-02-28
> MFT
> GAB
> TAFP
>
>
> Is this supposed to be or is this a cosmetic bug?
No reason. I think it just came out this way because there are so many
modes to handle, and you want some legible output in all of them.
I've removed outputting the extra newline in 9.3devel.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Query to find sum of grouped counts from 2 tables
On Friday, January 7, 2011 4:15:25 PM UTC+6, "Satish Burnwal (sburnwal)" wrote: > I have 2 tables containing the data for same items: > > STORE1 > - > Idtypeitems > - > 1 FOOD10 > 2 FOOD15 > 3 SOAP20 > > STORE2 > - > Idtypeitems > - > 1 FOOD15 > 3 SOAP10 > 4 PAPER 25 > 5 SOAP12 > > > What I am looking for is one single query that would return me TYPE-wise > total number of items from both the tables. UNION does not help me. I > want the result as: > > Type count > --- > FOOD 40 //10+15+15 > SOAP 42 //20+10+12 > PAPER 25 > > Thanks in advance, > -Satish > > -- > Sent via pgsql-general mailing list (pgsql-general@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general Hello, I think you can use the sum / count keyword on find query. Follow the link http://arafats.info/how-to-use-sum-on-cakephp/ Thanks http://arafats.info -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] PostgreSQL index issue
Hi Laurenz Many thanks for your reply. Could you please bit more explain about the following sentence you wrote: There are no performance problems except the ones that always come with an index: INSERTs, UPDATEs and DELETEs will be slower and do more disk I/O and locking. Many Thanks -- View this message in context: http://postgresql.1045698.n5.nabble.com/PostgreSQL-index-issue-tp5716336p5716459.html Sent from the PostgreSQL - general mailing list archive at Nabble.com. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] PostgreSQL index issue
On 07/13/2012 06:06 AM, codevally wrote: Hi Laurenz Many thanks for your reply. Could you please bit more explain about the following sentence you wrote: There are no performance problems except the ones that always come with an index: INSERTs, UPDATEs and DELETEs will be slower and do more disk I/O and locking. Every index you add slows down modifications to the table a little bit, because it has to be kept up to date. It also uses more disk space and takes time for VACCUM. -- Craig Ringer -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Bug? Prepared queries continue to use search_path from their preparation time
On 13/07/12 02:59, Greg Sabino Mullane wrote: -BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 This behavior is intentional. In that case, the error lies with the Perl libraries that automatically prepare and cache queries, but do not include the search_path in the cache keys. You have lost me there. Which Perl libraries are those? I was thinking of DBIx::Class, which will automatically use the DBI function prepare_cached() for all the queries it generates. However I discovered this warning hidden deep in the documentation: "[..] once your schema is instantiated, you should not change the PostgreSQL schema search path for that schema's database connection. If you do, Bad Things may happen." So they are aware of the problem, but unfortunately I hadn't seen that warning (and I suspect most users won't) until after they've encountered the problem. I guess for now I chalk this up to experience and remember not to do it again! :) -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] ERROR: out of shared memory - But the table is empty
On Thu, Jul 12, 2012 at 8:23 PM, Stefan Schwarzer wrote: > Hi there, > > not being an expert for Postgres…. I have a Postgis table with the > countries of the world. Now, I would like to drop it. I got the error > message: > > ERROR: out of shared memory > HINT: You might need to increase max_locks_per_transaction. > > and thought that it would be easier to drop first all rows, and then drop > the empty table. > > But it seems that it has a problem with dropping the index: > > DROP INDEX gis.countries_uid; > > actually generates that error message. > > So, do I need to dig now into the postgres config file? It seems strange > to me that Postgres has a problem deleting an empty table, though. > > The shared lock table has room for max_locks_per_transaction * max_connections entries,so as soon as it exceeds,you will get this error message. For fixing this issue,please set max_locks_per_transaction to (tables in database)/max_connections. Thanks & Regards, Raghu Ram EnterpriseDB Corporation Blog:http://raghurc.blogspot.in/
[GENERAL] hstore for audit logging: Finding differences between two hstore values
Hi all
I'm using Pg 9.1, working on enhancing my audit logging so it can record
not only the old and new values of a record when it changes, but what
exactly changed.
It's easy to produce hstore values for the old and new records, and I've
been happily logging those. I was about to start testing a switch to
'json' instead (for possible storage space savings and better composite
type support in exchange for poorer searchability) - when I found myself
wondering how I could log only the fields that changed using hstore.
A quick look at the hstore documentation (
http://www.postgresql.org/docs/9.1/static/hstore.html) doesn't reveal
any obvious key/value pairwise set operations like
union/intersection/difference. Am I missing something obvious?
Is there some clever way to get a hstore with only the _differing_ keys
of two input hstores? Or will I need to break them down into arrays and
manually find the differences?
For example, given:
regres=# select hstore('"x"=>"30", "y"=>"c"'), hstore('"x"=>"30",
"y"=>"fred"');
hstore| hstore
-+
"x"=>"30", "y"=>"c" | "x"=>"30", "y"=>"fred"
(1 row)
is there any straightforward operation between the two above hstores I
can use to produce a result like:
hstore('"y"=>"fred"');
, omitting the identical "x"=>"30" ?
I suspect I'd land up having to use each(...) to do a SQL set-oriented
difference using UNION/INTERSECT/EXCEPT, which will be "fun" in
performance terms. Please tell me there's a clever way I've missed.
I can do this:
regress=# select a.key, a.value from each(hstore('"x"=>"30", "y"=>"c"'))
AS a EXCEPT SELECT b.* FROM each(hstore('"x"=>"30", "y"=>"fred"')) b;
key | value
-+---
y | c
and aggregate it back into a hstore like this:
regress=# SELECT hstore( array_agg(diff.key), array_agg(diff.value) )
FROM (SELECT a.key, a.value from each(hstore('"x"=>"30", "y"=>"c"')) AS
a EXCEPT SELECT b.* FROM each(hstore('"x"=>"30", "y"=>"fred"')) b) AS diff;
hstore
--
"y"=>"c"
(1 row)
... but it feels like there must be a smarter way.
PostgreSQL 9.1.4 on x86_64-redhat-linux-gnu, compiled by gcc (GCC)
4.7.0 20120507 (Red Hat 4.7.0-5), 64-bit
Fedora 17
--
Craig Ringer
POST Newspapers
276 Onslow Rd, Shenton Park
Ph: 08 9381 3088 Fax: 08 9388 2258
ABN: 50 008 917 717
http://www.postnewspapers.com.au/
Re: [GENERAL] hstore for audit logging: Finding differences between two hstore values
On Fri, Jul 13, 2012 at 9:51 AM, Craig Ringer wrote: > ... but it feels like there must be a smarter way. Well, may be kind of (h1 - h2), (h2 - h1) and derivatives will make sense? -- Sergey Konoplev a database architect, software developer at PostgreSQL-Consulting.com http://www.postgresql-consulting.com Jabber: gray...@gmail.com Skype: gray-hemp Phone: +79160686204 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] installation problem with postgres password
Could you see anything wrong in the installation log? (%TEMP%\install-postgresql.log) On Thu, Jul 12, 2012 at 11:04 AM, KOTa wrote: > postgres user does not exist yet, its a fresh new installation of > windows 7 Home. New HP laptop. > there is only my account (admin) and Guest > > i saw on internet someone had similar problem and this was resolved by > removing HP protection tools tha was messing with policies, but i > already removed it before. > > On Thu, Jul 12, 2012 at 8:02 AM, raghu ram > wrote: > > > > > > On Thu, Jul 12, 2012 at 8:35 AM, KOTa wrote: > >> > >> that is what i though, but i tried many different combinations for > >> password, and at least 1 of them should satisfy policy requirements. > >> also my windows user password, which is accepted by OS and thus > >> satisfies the requirements resulted in same message > >> > >> i did try to see what policy is active, but i am using win 7 Home > >> Premium and i could find a way for this version to see/change > >> policies. > >> the only thing i found is by running "net accounts" from command > >> prompt. which shows the following: > >> > >> http://gyazo.com/be1089b5f0a1ebe6b8037ad9322eac31.png?1342061599 > >> > >> and those are very simple password policy which all combinations i used > >> satisfy > > > > > > Could you please try to reset the "postgres" user password in window7 > before > > reinstalling the PostgreSQL. Below link gives more information of > reseting > > password in windows7 > > > > http://pcsupport.about.com/od/windows7/ht/change-password-windows-7.htm > > > > Thanks & Regards, > > > > Raghu Ram > > > > EnterpriseDB Corporation > > > > Blog:http://raghurc.blogspot.in/ > > > > > > > > -- > Sent via pgsql-general mailing list (pgsql-general@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general > -- Regards, Sachin Srivastava EnterpriseDB, India
