On Tue, Jul 26, 2016 at 7:53 PM, John McKown
wrote:
> I agree. From my reading at:
> https://www.postgresql.org/docs/9.5/static/sql-copy.html the COPY FROM
> PROGRAM is only available to a PostgreSQL user who is database superuser.
> That, sort of, implies to me that said user is trusted not to d
On Tue, Jul 26, 2016 at 7:49 PM, David G. Johnston <
david.g.johns...@gmail.com> wrote:
> For superusers, no. You'd have to protect the system using external
> tools to limit what areas and commands the postgres (or whatever PostgreSQL
> runs as) user can access.
>
Thanks David for the informa
On Tue, Jul 26, 2016 at 6:59 PM, David G. Johnston <
david.g.johns...@gmail.com> wrote:
> Typically this means that given user only having psql, or some other
> backend protocol only, connect to the database are they able to execute
> arbitrary commands as the user running the PostgreSQL process
On Tue, Jul 26, 2016 at 6:54 PM, David G. Johnston <
david.g.johns...@gmail.com> wrote:
> Superuser: yes (specifically I'm thinking the COPY FROM PROGRAM command,
> but also C language functions)
> Ordinary user: not that I can think of.
>
OK, is there a way to restrict usage of COPY FROM PROGRA
On Tue, Jul 26, 2016 at 6:29 PM, Sameer Kumar
wrote:
You mean you don't want any routines/functions written in Pl/perl or
> PL/pythin to get executed?
>
> If that is what you are looking for them simply drop the extension for
> these languages or deny privilege to users/public on these extensions
On Tue, Jul 26, 2016 at 6:35 PM, David G. Johnston <
david.g.johns...@gmail.com> wrote:
> The way to go about prohibiting their usage altogether is specific to your
> installation method. But by default those languages are not installed into
> newly created databases and only a superuser can "CRE
Hello Experts,
I want to have my postgreSQL database to only execute SQLs and avoid
execution of perl and python script executions.
Can you please suggest ways to achieve this?
Regards...
On Tue, Jan 12, 2016 at 3:25 PM, John R Pierce wrote:
> On 1/12/2016 1:28 AM, Dev Kumkar wrote:
>
>
> I want to upgrade my database from version 9.3.4 to 9.3.10.
>
> For this task, do I need to upgrade database using pg_upgrade utility?
> <http://www.postgresql.org/docs/9
Hello,
I want to upgrade my database from version 9.3.4 to 9.3.10.
For this task, do I need to upgrade database using pg_upgrade utility?
http://www.postgresql.org/docs/9.3/static/pgupgrade.html
>From the details it looks like for minor version upgrade pg_upgrade utility
is not required.
"pg_u
Thanks Bill !
On Wed, Nov 26, 2014 at 9:07 AM, Bill Moran
wrote:
> In addition to what you're getting from that query, include the xact_start
> and
> state_change columns from pg_stat_activity. My guess is that your code is
> starting a transaction, then running a query, then processing the quer
Am debugging a race condition scenario where multiple transaction are
running in parallel and there are insert/update these transactions are
performing.
I was able to identify the blocking query and blocked query using following
SQL.
However observed the blocking query is holding the locks on the
On Fri, Nov 21, 2014 at 1:14 AM, Alvaro Herrera
wrote:
>
> If there are foreign keys on the tables, the system internally runs some
> SELECT FOR KEY SHARE queries on the referenced tables (the ones
> containing the primary or unique keys). You can get some multixacts
> that way too.
>
> --
> Álv
On Thu, Nov 20, 2014 at 11:15 PM, Alvaro Herrera
wrote:
> Search for "burnmulti" in the archives, which is a contrib module to
> test pg_multixact.
>
Thanks, got some links. Will give a try and get back.
Merely waiting does not, but more than one lock being acquired on a
> tuple does cause a mu
Hellos,
How to manually increase pg_multixact members and offsets?
Does a transaction waiting for exclusive lock or shared lock result into
entry being created in pg_multixact?
Excerpt of multixact.c:
/*-
2 *
3 * multixact
On Tue, Sep 30, 2014 at 8:50 PM, Alvaro Herrera
wrote:
> Did you try decreasing the autovacuum_multixact_freeze_min_age and
> autovacuum_multixact_freeze_table_age parameters?
>
As per the docs this set anywhere from zero to 1 billion for
vacuum_multixact_freeze_min_age
And zero to 2 billion for
On Fri, Sep 26, 2014 at 1:36 PM, Dev Kumkar wrote:
> Received the database with huge pg_multixact directory of size 21G and
> there are ~82,000 files in "pg_multixact/members" and 202 files in
> "pg_multixact/offsets" directory.
>
> Did run "vacuum full
On Fri, Sep 19, 2014 at 1:23 PM, Dev Kumkar wrote:
> Apologies for the delay, was working/troubleshooting same issue and was
> away from my emails. :(
> Regards...
>
Received the database with huge pg_multixact directory of size 21G and
there are ~82,000 files in "pg_multixact
On Fri, Sep 19, 2014 at 7:14 PM, Emanuel Calvo <
emanuel.ca...@2ndquadrant.com> wrote:
>
> Could it be related to some fixes on 9.3.5?:
>
> - Fix wraparound handling for pg_multixact/members (Álvaro Herrera)
> - Truncate pg_multixact during checkpoints, not during VACUUM (Álvaro
> Herrera)
>
Curr
On Fri, Sep 19, 2014 at 1:03 PM, Andres Freund
wrote:
> Yes: Learning some patience. You'd given the previous answer two hours
> before this one. Nobody is paid to work on this list...
Apologies for the delay, was working/troubleshooting same issue and was
away from my emails. :(
Regards...
On Fri, Sep 19, 2014 at 8:07 AM, Alvaro Herrera
wrote:
> Can you paste the pg_controldata output please?
>
pg_controldata output as follows:
pg_control version number:937
Catalog version number: 201306121
Database system identifier: 6023658189132429183
Databa
On Thu, Sep 18, 2014 at 6:20 PM, Dev Kumkar wrote:
> On Thu, Sep 18, 2014 at 4:03 PM, Andres Freund
> wrote:
>
>> I don't think that's relevant for you.
>>
>> Did you upgrade the database using pg_upgrade?
>>
>
> That's correct! No, there
On Thu, Sep 18, 2014 at 4:03 PM, Andres Freund
wrote:
> I don't think that's relevant for you.
>
> Did you upgrade the database using pg_upgrade?
>
That's correct! No, there is no upgrade here.
> Can you show pg_controldata output and the output of 'SELECT oid,
> datname, relfrozenxid, age(rel
On Thu, Sep 18, 2014 at 2:41 AM, Adrian Klaver
wrote:
>
> Aaah, hit enter too soon. Also see the other changes under Changes that
> apply to multixact in 9.3.5
Thanks for sharing same. Found this one interesting "Truncate pg_multixact
during checkpoints, not during VACUUM (Álvaro Herrera)" and
On Wed, Sep 17, 2014 at 7:20 PM, Dev Kumkar wrote:
> On Wed, Sep 17, 2014 at 6:51 PM, Adrian Klaver
> wrote:
>
>>
>> http://www.postgresql.org/docs/9.3/static/routine-
>> vacuuming.html#VACUUM-FOR-MULTIXACT-WRAPAROUND
>>
>
Looked into these details. Can the
On Thu, Sep 18, 2014 at 1:22 AM, Adrian Klaver
wrote:
> On 09/17/2014 12:26 PM, Dev Kumkar wrote:
>
>> I hope the binaries archive containing ""pgsql/share/postgresql/
>> timezone/Europe/Moscow" uploaded at
>> http://www.enterprisedb.com/products-services-
On Thu, Sep 18, 2014 at 12:01 AM, Tom Lane wrote:
> The next set of minor releases, whenever those are (and no, there's
> no schedule).
>
I hope the binaries archive containing ""pgsql/share/postgresql/
timezone/Europe/Moscow" uploaded at
http://www.enterprisedb.com/products-services-training/pg
On Wed, Sep 17, 2014 at 8:52 PM, Adrian Klaver
wrote:
>
> I am not that versed in the timezone handling to make a definitive
> statement. I would say it should work until you upgrade. At that point the
> new Moscow timezone should be correct and the change will not matter. I
> would verify on the
On Wed, Sep 17, 2014 at 7:20 PM, Dev Kumkar wrote:
> Thanks, yes have been looking into pg_stat_activity table and somehow the
> standard queries are hanging.
> Not sure if this is because the database response has become very slow.
>
Would having a huge pg_multixact directory have
On Wed, Sep 17, 2014 at 7:24 PM, Adrian Klaver
wrote:
> So you will need to determine what method you binaries use. If they are
> using the system timezone data, you will need to update that.
Thanks!
Just a hack here, how about copying
"pgsql/share/postgresql/timezone/Etc/GMT-3" as
"pgsql/shar
On Wed, Sep 17, 2014 at 6:53 PM, Andres Freund
wrote:
> On 2014-09-17 17:46:05 +0530, Dev Kumkar wrote:
> > On one my machine the pg_multixact directory size has grown up to 5 GB
> and
> > am not sure how to clean up this directory.
>
> Which version of postgres are
On Wed, Sep 17, 2014 at 6:51 PM, Adrian Klaver
wrote:
>
> http://www.postgresql.org/docs/9.3/static/routine-
> vacuuming.html#VACUUM-FOR-MULTIXACT-WRAPAROUND
>
> Might also want to take a look at pg_stat_activity to see what queries
> maybe hanging up:
>
>
> http://www.postgresql.org/docs/9.3/sta
Hello,
On one my machine the pg_multixact directory size has grown up to 5 GB and
am not sure how to clean up this directory.
>From the storage-file-layout this directory contains multitransaction
status data.
pg_multixactSubdirectory containing multitransaction status data (used for
shared row l
On Tue, Sep 16, 2014 at 6:16 PM, Dev Kumkar wrote:
> On Fri, Sep 12, 2014 at 7:31 PM, Adrian Klaver
> wrote:
>
>>
>> What OS and what packaging?
>>
>> For both windows-64-bit and Linux-64-bit.
> PostgreSQL version - 9.3.4
>
> I believe the file &quo
On Fri, Sep 12, 2014 at 7:31 PM, Adrian Klaver
wrote:
>
> What OS and what packaging?
>
> For both windows-64-bit and Linux-64-bit.
PostgreSQL version - 9.3.4
I believe the file "pgsql/share/postgresql/timezone/Europe/Moscow" will
require changes.
As the above changes will then be reflected in t
On Wed, Sep 10, 2014 at 8:43 PM, Tom Lane wrote:
> You'd want to get a new version of the IANA timezone database files for
> that. Depending on what packaging you're using, this might be an
> operating-system update not a Postgres update. If you are relying
> on the Postgres copies, you'd have
Hello,
I want to change the timezone to Europe/Moscow. Moscow timezone is changing
from +4 to +3
On the box, I have changed the timezone to MSK+3.
>From the db side I have modified the following files:
1)postgresql.conf
timezone = 'Europe/Moscow'
2)pgsql/share/postgresql/time
On Thu, Jun 5, 2014 at 11:03 PM, Magnus Hagander
wrote:
> Hi!
>
> The guys at EnterpriseDB are busy building new installers as we speak, I
> would expect them to be out tomorrow or so.
>
> --
> Magnus Hagander
> Me: http://www.hagander.net/
> Work: http://www.redpill-linpro.com/
>
Thanks for
On Wed, Apr 16, 2014 at 9:08 PM, Dev Kumkar wrote:
> On Wed, Apr 16, 2014 at 7:50 PM, Stephen Frost wrote:
>
>> * Dev Kumkar (devdas.kum...@gmail.com) wrote:
>> > I just downloaded the latest binaries from EnterpriseDB and when checked
>> > with libssl.so.1.0.0 can
On Tue, Apr 29, 2014 at 6:26 PM, Albe Laurenz wrote:
> Set "unix_socket_directory" (in versions before 9.3) or
> "unix_socket_directories" (from 9.3 on) in postgresql.conf.
>
> Yours,
> Laurenz Albe
>
Fantastic, thanks for this setting.
regards...
Faced following issue when trying to start database using pg_ctl:
FATAL: could not create lock file "/tmp/.s.PGSQL.5432.lock": Permission
denied
Accidentally someone cleaned up /tmp and recreated it but without any write
permissions to non-root user, if the non-root user write permissions are
gi
On Thu, Apr 17, 2014 at 1:31 AM, John R Pierce wrote:
> do you enable SSL and expose it to an insecure network ? if not, no
> exposure to the heartbleed bug.
>
No, SSL is not enabled in my case but also wanted to make sure there is no
binary available which can later result into any potential
On Thu, Apr 17, 2014 at 12:53 AM, John R Pierce wrote:
> windows native stuff uses completely different TLS libraries, SChannel and
> stuff. AFAIK, these aren't subject to this bug, which was specific to
> OpenSSL 1.0.1x for x=a-f...openssl is only used on windows when someone
> uses it expl
Hey,
What is the windows equivalent of libssl.so.1.0.0 ?
Please reply as this is really becoming priority for me.
Regards...
On Wed, Apr 16, 2014 at 6:49 PM, Albe Laurenz wrote:
> Dev Kumkar wrote:
> >> Unless somebody changes the setting to ssl=on, there should be no
> problem.
>
> > Thanks also please help to understand - does changing this
> postgresql.conf setting enough to be
> > v
On Wed, Apr 16, 2014 at 7:50 PM, Stephen Frost wrote:
> * Dev Kumkar (devdas.kum...@gmail.com) wrote:
> > I just downloaded the latest binaries from EnterpriseDB and when checked
> > with libssl.so.1.0.0 can see this:
> > OpenSSL 1.0.1g 7 Apr 2014
> >
> > Open
On Wed, Apr 16, 2014 at 6:54 PM, Stephen Frost wrote:
>
> Yeah, I'm doing that already and they're looking into it right now.
>
> Thanks,
>
> Stephen
>
I just downloaded the latest binaries from EnterpriseDB and when checked
with libssl.so.1.0.0 can see this:
OpenSSL 1.0.
On Wed, Apr 16, 2014 at 5:28 PM, Dev Kumkar wrote:
> On Wed, Apr 16, 2014 at 4:57 PM, Boszormenyi Zoltan wrote:
>
>> The package version and the soversion are only loosely related.
>> E.g .the upstream OpenSSL 1.0.0 and 1.0.1 series both ship soversion
>> 1.0.0.
>&
On Wed, Apr 16, 2014 at 3:18 PM, Albe Laurenz wrote:
>
> Unless somebody changes the setting to ssl=on, there should be no problem.
>
> Yours,
> Laurenz Albe
>
Thanks also please help to understand - does changing this postgresql.conf
setting enough to be vulnerable here?
Regards...
On Wed, Apr 16, 2014 at 4:57 PM, Boszormenyi Zoltan wrote:
> The package version and the soversion are only loosely related.
> E.g .the upstream OpenSSL 1.0.0 and 1.0.1 series both ship soversion 1.0.0.
>
> Best regards,
> Zoltán Böszörményi
of which OpenSSL package versions' libssl.1.0.0.so is
We are using postgresql binaries downloaded from here
http://www.enterprisedb.com/products-services-training/pgbindownload
The binaries which are currently at 9.3.3 were updated when the security
vulnerabilities were announced in Feb 2014.
We embed certain binaries and libssl.so.1.0.0 gets shippe
On Thu, Apr 3, 2014 at 11:52 PM, Andy Colson wrote:
>
> You realize its an April fools joke, right?
>
> I think I can hear David's evil laugh from here :-)
>
> -Andy
>
Ya, actually did realize the same time when it got posted as was online
that time. ;)
Regards...
On Tue, Apr 1, 2014 at 7:10 PM, David Fetter wrote:
> == PostgreSQL Weekly News - April 01 2014 ==
>
> PostgreSQL 10.0 Released.
> This release includes built-in, tradeoff-free multi-master
> replication, full integration with all other data stores, and a broad
> choice of SQL query dialects incl
On Tue, Apr 1, 2014 at 7:58 PM, Devrim Gündüz wrote:
> Hi,
>
> It works fine. We already branched RHEL 7 RPMs. I am using them on my
> testing instance.
>
> Regards,
>
Hi Devrim,
Thanks for the quick update !
Regards...
Hello,
RHEL 7 will be in market by June 2014.
I just wanted to check here RHEL 7 and Postgres 9.3.4 compatibility?
Regards...
On Thu, Mar 27, 2014 at 7:11 PM, Adrian Klaver wrote:
> Search on:
>
> fortify software database
>
> found:
>
> http://www.hpenterprisesecurity.com/vulncat/en/vulncat/index.html
>
> This indicates Postgres is not supported.
>
>
> Search on
>
> fortify open source alternatives
>
> found:
>
> https:
On Thu, Mar 27, 2014 at 1:36 AM, Dev Kumkar wrote:
> On Thu, Mar 27, 2014 at 1:31 AM, John R Pierce wrote:
>
>> why don't you ask the Fortify vendor ?
>
>
> Yup, following up with them in parallel.
> Search didn't gave me any good links, so wanted to check wit
On Thu, Mar 27, 2014 at 1:31 AM, John R Pierce wrote:
> why don't you ask the Fortify vendor ?
Yup, following up with them in parallel.
Search didn't gave me any good links, so wanted to check with community too
here.
If not Fortify, is there any other such tool?
Regards...
Is Fortify supported for PostgreSQL?
Any auditing tool which you suggest to check the schema design, roles and
functions and other aspects?
I have used fortify for oracle and sybase, but just not sure about
postgreSQL?
Can anyone provide some pointers here and if not Fortify then any such tool?
On Thu, Feb 27, 2014 at 11:17 PM, Adrian Klaver
wrote:
> That works because you said NULL is a valid value for the column. If you
> had specified NOT NULL then you would get an error about violating the NOT
> NULL constraint. Since you have said NULL is a valid value and you actually
> specified i
On Thu, Feb 27, 2014 at 9:32 PM, Adrian Klaver wrote:
>
> Realized my previous answer:
>
> col_2 = coalesce(my_test.col_2, NEW.col_2)
>
> works for the particular situation you described, but not for the general
> case. It would not allow an update of a field where a NON NULL value exists
> and yo
Am facing issues with using UPSERT rule having default value columns.
Here is the code:
create table my_test (id int, col_1 timestamp null, col_2 varchar(12) null
default 'Initial');
CREATE OR REPLACE RULE RULE_my_test AS ON INSERT TO my_test WHERE EXISTS
(SELECT 1 from my_test WHERE id = NEW.i
On Fri, Feb 21, 2014 at 12:43 AM, Andrew Sullivan wrote:
> Do you control the client code? If so, why not set the TimeZone
> locally when you connect? That's the right way to handle this,
> really.
>
Agree. So find the OS timezone at programming level and set accordingly.
This can be done eithe
On Fri, Feb 21, 2014 at 1:26 AM, Adrian Klaver wrote:
> Well I dug out a Windows machine and tried to get what you wanted, to no
> avail. As far as I know there is no UTF8 collation, it is an encoding. What
> you want if I am following, is the en_US locale (or equivalent for another
> language) on
On Fri, Feb 21, 2014 at 12:14 AM, Gavin Flower <
gavinflo...@archidevsys.co.nz> wrote:
> On 21/02/14 02:04, Dev Kumkar wrote:
>
> On Thu, Feb 20, 2014 at 3:04 AM, Gavin Flower <
> gavinflo...@archidevsys.co.nz> wrote:
>
>> Upgrade servers to Linux? :-P
>>
On Thu, Feb 20, 2014 at 9:30 PM, Adrian Klaver wrote:
>
> So what is your requirement?
> Do you have a specific application/use for the databases you are
> installing?
There are two interfaces for the database. One is from the ODBC driver and
other is from the JDBC driver.
These are the two clie
On Thu, Feb 20, 2014 at 3:04 AM, Gavin Flower wrote:
> Upgrade servers to Linux? :-P
>
Actually that's not the solution but running away from it.
There is a heavy footprint of customers and huge market on windows too and
so not that easy to migrate and convince in market.
Regards...
On Thu, Feb 20, 2014 at 4:31 AM, Adrian Klaver wrote:
> It depends on how you are declaring the timestamp field. If you do not use
> with time zone then the input value is open to interpretation and is not
> 'anchored' to a point in time.
>
> Example
>
> My time zone is currently PST.
> test=> cr
inline:
On Thu, Feb 20, 2014 at 3:57 AM, Tom Lane wrote:
>
> The functionality of determining an IANA timezone name equivalent to the
> platform's behavior is currently embedded in initdb and isn't separately
> accessible. So you've got several options:
>
Hmm, actually was looking for exact that
On Thu, Feb 20, 2014 at 3:55 AM, Terence Ferraro
wrote:
> Or, if you don't mind a little patching: http://pastebin.com/5AyaX2RF
>
> That restores the pre-9.1 functionality of determining the timezone on
> postmaster start. As has been pointed out, their new stuff is more useful
> if you're shippin
On Thu, Feb 20, 2014 at 3:53 AM, Adrian Klaver wrote:
> Each driver will have its own behavior. For an explanation of the JDBC
> behavior see here:
>
> http://www.postgresql.org/message-id/4b2f2ced.10...@opencloud.com
>
>
> Per Andrews posts, the least surprise behavior is to explicitly set the
>
On Thu, Feb 20, 2014 at 4:34 PM, Daniel Verite wrote:
> Despite windows-1252 being a monobyte encoding sharing most
> of LATIN1 codes and character set, it does not mean that
> English_United States.1252 is limited to this character set.
> You may use UTF-8 databases with that locale.
>
> Consider
On Thu, Feb 20, 2014 at 3:40 AM, Andrew Sullivan wrote:
> I think your client should set the TimeZone at connection time.
> That's going to yield the most predictable behaviour for the users, I
> suspect.
Agree! But nothing special is done at JDBC level, is the JDBC driver
setting things like Ti
On Thu, Feb 20, 2014 at 3:26 AM, Andrew Sullivan wrote:
> On Thu, Feb 20, 2014 at 03:22:15AM +0530, Dev Kumkar wrote:
> >
> > Hmm. Missed one observation here, created a test table with timestamp
> > column of type 'default current_timestamp'.
> > When th
On Thu, Feb 20, 2014 at 3:17 AM, John R Pierce wrote:
> On 2/19/2014 1:35 PM, Adrian Klaver wrote:
>
>>
>> Unfortunately this is a Windows install and that does not work either.
>>
>
> windows encodings are a pain. their Unicode is NOT utf8, its ucs2 aka
> utf16. I just checked my default ins
On Thu, Feb 20, 2014 at 3:07 AM, Adrian Klaver wrote:
>
> Do you know where the machine is going when you do the install?
No if that was the case then target could have set before shipping itself.
Machine TGT-Region is not known here.
Regards...
On Thu, Feb 20, 2014 at 2:49 AM, Andrew Sullivan wrote:
> No, select now() would return the time in whatever timezone is set, or
> the timezone that the server defaulted to if there's nothing set by
> the client. So in your installation, set up the server to use UTC by
> default and, if you like,
On Thu, Feb 20, 2014 at 2:45 AM, Adrian Klaver wrote:
>
> Have you tried it?
>
> Note that the locale name is different then the one Linux.
>
> On Linux it is en_US.
>
> What I suggested is en-US.
>
Yes. Here is the output:
createdb -U postgres -E utf8 -l en-US -T template0 mynewdb
Password:
*cre
On Thu, Feb 20, 2014 at 2:32 AM, Andrew Sullivan wrote:
> Try issuing SET TimeZone commands. I think you'll find that the
> client can set whatever time zone it wants.
I think am not being heard incorrectly here.
Here is the scenario - Database is created using binaries and not
postgreSQL inst
On Thu, Feb 20, 2014 at 2:24 AM, Adrian Klaver wrote:
> Alright last shot:)
>
> Taking hint from here:
>
> http://msdn.microsoft.com/en-us/library/x99tb11d.aspx
>
> try:
>
> createdb -U postgres -E utf8 -l en-US
>
> If that does not work, not sure where to go.
This won't work on Windows. Note t
On Thu, Feb 20, 2014 at 2:06 AM, John R Pierce wrote:
> postgres handles timezones on a per client connection basis. the server
> itself doesn't really care what timezone it is running in. 'timestamp with
> time zone' data is internally stored in the equivalent of UTC, and
> converted to/from th
On Thu, Feb 20, 2014 at 2:01 AM, Adrian Klaver wrote:
> Just noticed you are not specifying the template database. Try using
> template0:
>
> createdb -U postgres -E utf8 --lc-ctype=american_usa
> --lc-collate=american_usa -T template0
Same result i.e. LC_COLLATE and LC_CTYPE gets set as 'Engl
On Thu, Feb 20, 2014 at 1:41 AM, Adrian Klaver wrote:
> What does it set LC_CTYPE to?
>
> So what happens if you do?:
>
> createdb -U postgres -E utf8 -l american_usa.65001
>
*createdb: database creation failed: ERROR: invalid locale name:
"american_usa.65001" *
> or
>
> createdb -U postgres
On Thu, Feb 20, 2014 at 1:19 AM, Adrian Klaver wrote:
> So what is the exact command you are using?
createdb -U postgres -E utf8 -l american_usa
Above command fails to create utf-8 LC_COLLATE.
Regards...
On Wed, Feb 19, 2014 at 8:31 PM, Tom Lane wrote:
> If you mean you would like to use Windows' timezone data, the answer is
> you can't --- and you generally shouldn't want to, because AFAIK their
> timezone data is pretty sucky: it's incomplete and not terribly accurate
> about historical details
On Wed, Feb 19, 2014 at 10:16 PM, Adrian Klaver
wrote:
> I found the below that might help. I do not use Windows much any more so I
> do not have a machine handy to confirm.
>
> http://www.g-loaded.eu/2011/02/27/locale-windows/
>
Thanks for the pointer. "*american_usa*" works however it sets the
Am really going no where with this after so many searching over net or am
missing some basic things, not sure!
What is the equivalent for "en_US.UTF-8" collation in case of windows?
In Linux am creating database with following options, as follows:
-E utf8 -l en_US.UTF-8 -T template0
This creates
How to set timezone in postgreSQL database to pick operating system level
timezone information.
In postgresql.conf there exists "timezone" parameter whose value can be set.
However this value needs to be in format 'US/Pacific', 'Asia/Calcutta' and
so on to work correctly.
Is there any database qu
On Thu, Dec 12, 2013 at 12:47 PM, Dev Kumkar wrote:
> + hackers
>
>
>
> On Thu, Dec 12, 2013 at 12:34 PM, Dev Kumkar wrote:
>
>> On Wed, Dec 11, 2013 at 9:47 PM, Dev Kumkar wrote:
>>
>>> Actually for searches lower will work.
>>> But the other im
+ hackers
On Thu, Dec 12, 2013 at 12:34 PM, Dev Kumkar wrote:
> On Wed, Dec 11, 2013 at 9:47 PM, Dev Kumkar wrote:
>
>> Actually for searches lower will work.
>> But the other important aspect is 'inserts' which would result 2 rows if
>> the values are '
On Wed, Dec 11, 2013 at 9:47 PM, Dev Kumkar wrote:
> Actually for searches lower will work.
> But the other important aspect is 'inserts' which would result 2 rows if
> the values are 'A' and 'a'. Intent here to have it case insensitive.
>
> If
ec 11, 2013 at 8:58 PM, Andrew Sullivan wrote:
> On Wed, Dec 11, 2013 at 04:55:07PM +0530, Dev Kumkar wrote:
> You could build lower() indexes on any column you want to search CI
> and lower() all the input text during searches, in order to avoid any
> work on the schema. Bit of a kludge, though.
>
> Best,
>
> A
>
Can case-insensitive collation help here?
On Wed, Dec 11, 2013 at 4:55 PM, Dev Kumkar wrote:
> Thanks John.
>
> Yes CITEXT would work, the only thing its needs DDL changes across and
> hence was looking for any such global database parameter setting while
> creating databa
Resending...
On Wed, Dec 11, 2013 at 8:29 PM, Dev Kumkar wrote:
> Yes actually that's one alternate solution to use cron or windows
> scheduled tasks.
>
> The intent is to call certain stored procedures at certain time intervals.
>
>
> On Wed, Dec 11, 2013 at 7
How to create scheduled events in postgres simillar to whats event in
Sybase.
Is there any method of doing so?
Also am looking at PgAgent which can create jobs but is it similar like
events in sybase.
Please suggest.
Regards...
case
insensitive.
regards...
On Wed, Dec 11, 2013 at 12:10 PM, John R Pierce wrote:
> On 12/10/2013 10:31 PM, Dev Kumkar wrote:
>
>> I know about CITEXT data type, but what am looking for is if there any
>> parameter at database level which just makes the database case inse
How to create case insensitive database?
I know about CITEXT data type, but what am looking for is if there any
parameter at database level which just makes the database case insensitive.
I mean both values 'ABC' and 'abc' are treated same for inserts and also
all the comparisons by default are c
On Wed, May 22, 2013 at 6:06 PM, Dev Kumkar wrote:
> On Wed, May 22, 2013 at 4:10 PM, Devrim GÜNDÜZ wrote:
>
>>
>> Yes, or, as mentioned before, you can simply download the RPM directly
>> from the repo.
>>
> Thanks Devrim!
>
> Installed postgres-92
On Tue, May 21, 2013 at 11:28 PM, Dev Kumkar wrote:
> On Tue, May 21, 2013 at 10:49 PM, John R Pierce wrote:
>
>> its looking for the RPM installed packages it was linked against. its not
>> looking to see if any same named files just happen to be on your system.
>
>
>
On Tue, May 21, 2013 at 7:25 PM, Dann Corbit wrote:
> >>
>
> I do not know if you have 64 bit or 32 bit Linux and if it is Redhat or
> Mandrake or whatever.
>
> To be clear:
>
> The PostgreSQL distribution allows you to download the PostgreSQL ODBC
> driver. The PostgreSQL ODBC driver i
On Wed, May 22, 2013 at 4:10 PM, Devrim GÜNDÜZ wrote:
>
> Yes, or, as mentioned before, you can simply download the RPM directly
> from the repo.
>
Thanks Devrim!
Installed postgres-92 server from
postgresql92-server-9.2.4-1PGDG.rhel5.x86_64.rpm, actually links which John
(Thanks!) mentioned wer
1 - 100 of 165 matches
Mail list logo
