Re: OFF-TOPIC [GENERAL] Gist Index: Problem getting data in GiST Support Functions "penalty".
-Original Message- From: pgsql-general-ow...@postgresql.org [mailto:pgsql-general-ow...@postgresql.org] On Behalf Of Michael Gould Sent: Monday, June 27, 2011 8:13 PM To: 'pgsql-general@postgresql.org' Subject: Re: [GENERAL] Gist Index: Problem getting data in GiST Support Functions "penalty". I am running 9.0.4 and I'm running it on Windows 7 Ultimate which is my development machine. This is becoming a huge problem for me. I need to have the schema imported into the database by Thursday of this week when we are supposed to show off a new module in our product. We've not had any problems in other customer locations trying to get in. Any ideas? >>> A) The message you have sent has nothing to do with the thread that you sent it on. B) You have not provided enough information for someone to even attempt a guess at what the problem may be. Specifically, your description of what machines and networks are involved is inadequate AND you do not provide the postgres.conf file contents for the server. You should probably start a new thread, with more information, to increase your chances of actually getting a response. 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] Gist Index: Problem getting data in GiST Support Functions "penalty".
I am running 9.0.4 and I'm running it on Windows 7 Ultimate which is my development machine. I can't even create a server. When I try I get a message The server doesn't accept connections: the connection library reports could not connect to server: Connection refused (0x274D/10061) Is the server running on host "192.168.1.150" and accepting TCP/IP connections on port 5432? PostGres has been given access through the firewall on port 5432. My pg_hba.config file has the following line # TYPE DATABASEUSERCIDR-ADDRESSMETHOD # IPv4 local connections: hostall all 0.0.0.0/0 trust I am just trying to get logged in at this point so I'm basically not trying to use any security. This is becoming a huge problem for me. I need to have the schema imported into the database by Thursday of this week when we are supposed to show off a new module in our product. We've not had any problems in other customer locations trying to get in. Any ideas? Best Regards Michael Gould -- 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] Live records and number of records are differents...
On 06/27/2011 11:12 PM, F T wrote: - but the number of live rows is 772308... The UI should really say something like "Stats: Estimated number of live rows: 772308" to indicate more clearly what's going on. At least putting it under a "Statistics and Estimates" heading/category would help. -- 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] Custom types as parameter in stored function
On Mon, Jun 27, 2011 at 2:22 PM, mephysto wrote: > Thank you Merlin. > > Now, Can I pass the select as an argument of my function? sure: select myfunc(populate_record(null::t, 'b=>9, a=>2')); merlin -- 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] Custom types as parameter in stored function
Thank you Merlin. Now, Can I pass the select as an argument of my function? Or must I do in other manner? Sorry, but I am a novice. Best regards. Mephysto -- View this message in context: http://postgresql.1045698.n5.nabble.com/Custom-types-as-parameter-in-stored-function-tp4527618p4529531.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] glitch installing xml support in 9.1.beta2
On 06/25/2011 01:10 AM, Guillaume Lelarge wrote: > On Fri, 2011-06-24 at 11:22 -0600, Rob Sargent wrote: >> OpenSuse 11.4 x86-64 >> >> gmake install builds and places the requisite pieces as expected. >> >> Running >> psql --username postgres -d postgres -f xml2--1.0,sql >> results in >> psql:xml2--1.0.sql:8: ERROR: function "xml_valid" already >> exists with same argument types >> psql:xml2--1.0.sql:12: ERROR: could not access file >> "MODULE_PATHNAME": No such file or directory >> psql:xml2--1.0.sql:16: ERROR: could not access file >> "MODULE_PATHNAME": No such file or directory >> psql:xml2--1.0.sql:20: ERROR: could not access file >> "MODULE_PATHNAME": No such file or directory >> psql:xml2--1.0.sql:24: ERROR: could not access file >> "MODULE_PATHNAME": No such file or directory >> psql:xml2--1.0.sql:28: ERROR: could not access file >> "MODULE_PATHNAME": No such file or directory >> psql:xml2--1.0.sql:34: ERROR: could not access file >> "MODULE_PATHNAME": No such file or directory >> (This from second run, so xml_valid worked the first time). >> >> I see that the xml2.control file defines module_pathname = >> '$libdir/pgxml', but how is that passed to the psql run? Or am I to >> manually update the sql scripts? >> . > You don't use it explicitely. You use "CREATE EXTENSION", and it will > use it. > > psql --username postgres -d postgres -c "CREATE EXTENSION xml2" > > and it should work. That's one of the great things in 9.1. > Worked perfectly for xml2 thanks. As for uuid I had to run the extendor like this: psql --username=postgres -d postgres -c 'create extension "uuid-ossp"' Unfortunate hyphenation in the name of the module. -- 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] In a view, how do I cause fields with possible NULLs to be treated as a blank string in a replace operation?
Either use '' as some_type, or use COALESCE(some_type, ''). On Mon, Jun 27, 2011 at 9:53 AM, Asfand Qazi (Sanger Institute) < aq2.san...@gmail.com> wrote: > Hello, > > So I have am playing with a view to test the feasibility of a > technique for storing some data. > > It basically goes something like this: > > CREATE VIEW formatted_table AS > SELECT name, > replace(some_template, '@', some_type) AS some_field > FROM some_table; > > some_template is something like 'foo@bar' or 'foobar' (note the > missing template character). > > some_type is a single letter like 'a' or 'b', or it can be NULL. > > The above view works fine for rows where some_type is a letter, and > some_field ends up as 'fooabar' or whatever. > > However, when some_type is NULL, some_field ends up as NULL as well. > I understand that this is expected behaviour, but how do I cause the > view to treat a some_type of NULL as an empty string, so that > some_field simply ends up as 'foobar'? > > Hope that was clear. > > -- > Sent via pgsql-general mailing list (pgsql-general@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general > -- Rick Genter rick.gen...@gmail.com
Re: [GENERAL] In a view, how do I cause fields with possible NULLs to be treated as a blank string in a replace operation?
On 27 June 2011 17:53, Asfand Qazi (Sanger Institute) wrote: > Hello, > > So I have am playing with a view to test the feasibility of a > technique for storing some data. > > It basically goes something like this: > > CREATE VIEW formatted_table AS > SELECT name, > replace(some_template, '@', some_type) AS some_field > FROM some_table; > > some_template is something like 'foo@bar' or 'foobar' (note the > missing template character). > > some_type is a single letter like 'a' or 'b', or it can be NULL. > > The above view works fine for rows where some_type is a letter, and > some_field ends up as 'fooabar' or whatever. > > However, when some_type is NULL, some_field ends up as NULL as well. > I understand that this is expected behaviour, but how do I cause the > view to treat a some_type of NULL as an empty string, so that > some_field simply ends up as 'foobar'? > > Hope that was clear. Try coalesce: http://www.postgresql.org/docs/9.0/static/functions-conditional.html#AEN15541 So if foo is a null value, and you used COALESCE(foo, 'bar'), the output would be 'bar', otherwise it would be whatever the value of foo is. -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935 EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] In a view, how do I cause fields with possible NULLs to be treated as a blank string in a replace operation?
Hello, So I have am playing with a view to test the feasibility of a technique for storing some data. It basically goes something like this: CREATE VIEW formatted_table AS SELECT name, replace(some_template, '@', some_type) AS some_field FROM some_table; some_template is something like 'foo@bar' or 'foobar' (note the missing template character). some_type is a single letter like 'a' or 'b', or it can be NULL. The above view works fine for rows where some_type is a letter, and some_field ends up as 'fooabar' or whatever. However, when some_type is NULL, some_field ends up as NULL as well. I understand that this is expected behaviour, but how do I cause the view to treat a some_type of NULL as an empty string, so that some_field simply ends up as 'foobar'? Hope that was clear. -- 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] Custom types as parameter in stored function
On Mon, Jun 27, 2011 at 4:33 AM, mephysto wrote: > Hello to everyone, > I am trying to pass custom types as parameters in stored functions, and I > tried this syntax successfully: > > create type myType as (id bigint, name character varying); > > > create or replace myfunc(obj myType) > returns void as > begin > ... > end; > > > select myfunc((1, 'foo')::myType; > > > In this manner, if I understand it, there is a positional assignment of > attribute value: id = 1 and name = foo. > My ask is is there a manner to assing value to attribute of custom type by > name instead by position. You can do it via hstore in 9.0+...just be aware it is slower than the row constructor method. See the example below -- note CREATE EXTENSION is a 9.1 feature -- to do it in 9.0 you have to install the contrib script manually. postgres=# create extension hstore; WARNING: => is deprecated as an operator name DETAIL: This name may be disallowed altogether in future versions of PostgreSQL. CREATE EXTENSION postgres=# create type t as (a int, b text); CREATE TYPE postgres=# select populate_record(null::t, 'b=>9, a=>2'); populate_record - (2,9) merlin -- 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] Live records and number of records are differents...
On Mon, Jun 27, 2011 at 4:12 PM, F T wrote: > Hello list, > > I use PostgreSQL 8.4 and Postgis 1.4. > > I use FME to insert 772185 records in a table (multipolygons that represent > parcels). > > Everything seems fine but... > If I type select count(*), I get the right number of records : 772185 > records. > > But If I use pgAdmin and have a look in the stats : > - row inserted = 772185 OK fine, > - but the number of live rows is 772308... > > I don't understand why the number of live rows and the number of rows is > différent... > Any explaination would be very appreciated ! > Thanks you > PgAdmin uses the statistical information , that's updated by (auto)vacuum and not running the actual select count(*) I believe. -- GJ -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Live records and number of records are differents...
Hello list, I use PostgreSQL 8.4 and Postgis 1.4. I use FME to insert 772185 records in a table (multipolygons that represent parcels). Everything seems fine but... If I type select count(*), I get the right number of records : 772185 records. But If I use pgAdmin and have a look in the stats : - row inserted = 772185 OK fine, - but the number of live rows is 772308... I don't understand why the number of live rows and the number of rows is différent... Any explaination would be very appreciated ! Thanks you Fabrice <> -- 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] to_timestamp() and timestamp without time zone
From: pgsql-general-ow...@postgresql.org [mailto:pgsql-general-ow...@postgresql.org] On Behalf Of hernan gonzalez Sent: Sunday, June 26, 2011 3:57 PM To: pgsql-general@postgresql.org Subject: Re: [GENERAL] to_timestamp() and timestamp without time zone An analogy: a "localtime" is like a "relative path" in a filesystem. A full datetime spefication (date, time, timezone) would correspond to a absolute path. So let us call it "Relative Time" instead of "Abstract/Local Time". I like this better since the term relative begs the question: "relative to what" which then needs to be answered (by adding a TimeZone) to possibly represent an Instant (or absolute time). However there is no guarantee that the process of turning the relative path into an absolute path will succeed just as there is no guarantee that a relative time exists when associated with a specific TimeZone. First: I would suggest your use of "Local Time" is incorrect and that you would be better off thinking of it as "Abstract Time". My responses below go into more detail but in short you obtain a "Local" time by "Localizing" and "Abstract" time. The process of "Localization" requires a relevant "Locale" input which, for date/time values, is a "TimeZone". That's not the way in which the expression "Local (date) time" is normally used, rather the opossite. A "localtime" is normally a time which is to be understood relatively to some unespecified timezone. Precisely, when we (in common usage) specify a datetime, we say a date, a time and then either add some specific timezone OR do not state it : just say "localtime". That is, we either say "The event happened 2011-10-03 12:00:00 , Eastern Time" OR we say "The event happened 2011-10-03 12:00:00 (localtime)" "International offices will close the first semester at 2011-06-31 23:59:00 (localtime)" In all the above examples the use of the "localtime" simply means "in the timezone in which the event physically happened or in which the post offices are physically located. It is exactly in this sense that I suggest LocalTime be used. The TimeZone itself may or may not be known but it is implied and present none-the-less. This make sense because any time specification of a physical event can and is specified by an instant. In fact, in pretty all common usage we are dealing with Instances and not "Relative Time". This is because we are dealing with the past and thus the "location" is already known. It is when the location is unknown, in the future or if there could be multiple, that you supply the Abstract Time to the user and let them figure out at what Instant they should do something. So, saying "go to bed at 2AM local time" means "bed time is 2AM no matter where you are; when you arrive someplace attach your current TimeZone to the 2AM Abstract Time and go to bed at that Instant. That's also how the word is used in APIs (see Joda time) The Joda-Time API indeed defines its "LocalTime" is the same manner as I've suggested defining "Relative Time"; I would argue that their use of "LocalTime" is also mis-guided for the reasons already stated. Saying that someone else does something is generally a poor defense for a position. Group-think is useful but, as in this case, your supporting group is fallible; they made the same mistake as you (or rather your parroting of their position reflected their mistake as well). It is a subtle and inconsequential mistake since most people would make the same one and the actual definitions and implementations are consistent and serve the needed purpose. In the same way "timestamp" and "timestamptz" have their own "mistakes" surrounding them (due to the re-characterization during the version 7.x timeline) but they are consistently defined and implemented and provide the same two models that Joda-Time does - just under different labels. One sensible paraphrase of "LocalTime" - to include the prefix "local" - is "A time value that needs to be localized in order to possibly represent an instant." This works but for this, as for other things generally, I first determine what it is I need to represent and then I scan the documentation for Names that seems to do similar things. I then read the description so see whether I have found the correct one. Naming perfection is not required; as long as the label is close in meaning I'll generally find what is needed if it is there. Then I just associate that API/label with the behavior/feature I need and use it simply as-is - without an in-depth analysis of whether it is fully logical since - in programming - it is difficult to fix public "mistakes". David J.
Re: [GENERAL] discard on constraint violation
>>My situation is that I'm reading data from an external website with lots of duplicate data. I am reading the data in a plpythonu function. I never update, only insert. A trigger on the table that has to check if each row exists before trying the insert is too much overhead. Create a staging table into which you import your external data and then write a query of the form "INSERT INTO realtable SELECT FROM stagingtable WHERE stagingtable NOT EXISTS realtable". 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] Reusing cached prepared statement slow after 5 executions
This behavior is in some way needed, as PreparedStatement is, commonly, used once, just to pass parameters without escaping. Regards, Radek -Original Message- From: Rob Gansevles Sent: 27 czerwca 2011 08:50 To: pgsql-general Subject: Re: [GENERAL] Reusing cached prepared statement slow after 5 executions I can confirm, when I call ps.setPrepareThreshold(1) the query is slow immediately, so the plan must be different with the server prepared statements. Thanks, Rob On Sun, Jun 26, 2011 at 5:11 PM, Tom Lane wrote: > David Johnston writes: >> This is likely the case where the first few "prepared statements" are >> not truly prepared. Once you hit five the cache kicks in and computes >> a generic query plan to cache. > > Not so much that as that JDBC decides that it should tell the backend to > start using a prepared plan. See the JDBC docs. > > 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 -- 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] discard on constraint violation
On Mon, 2011-06-27 at 15:36 +0300, Sim Zacks wrote: > Is there a way to tell a table to discard an insert if it violates a > constraint (unique in my case) instead of giving an error? I don't want > the overhead of a trigger on each row inserted. > Without a trigger, you can't. -- Guillaume http://blog.guillaume.lelarge.info http://www.dalibo.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] An amusing MySQL weakness--not!
Le lundi 27 juin 2011 à 12:11 +0200, Leif Biberg Kristensen a écrit : > PHP has its own Boolean values TRUE/FALSE, but reads Postgresql > Booleans as > 't'/'f'. You always have to rely on kludgy konstructs like > > if ($pg_bool == 't') then > $my_bool = TRUE; > elseif ($pg_bool == 'f') then > $my_bool = FALSE; > else > $my_bool = NULL; > > It's of course much easier to use integer values, but it sucks not to > use a > bool when you want a variable that can't be anything but TRUE, FALSE > or NULL. > Same thing with Perl. But I am starting to think that the benefits of data integrity mentionned by Stephen are worth the extra effort : you save on validation needs anyway, which is probably another couple of lines, if not more, and less reliable. -- Vincent Veyron http://marica.fr/ Logiciel de gestion des sinistres et des contentieux pour le service juridique -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] discard on constraint violation
Is there a way to tell a table to discard an insert if it violates a constraint (unique in my case) instead of giving an error? I don't want the overhead of a trigger on each row inserted. My situation is that I'm reading data from an external website with lots of duplicate data. I am reading the data in a plpythonu function. I never update, only insert. A trigger on the table that has to check if each row exists before trying the insert is too much overhead. I tried in plpython: create or replace function testme() returns bool as $$ try: plpy.execute("insert into reports.survey_types(typeid,name)values(1,'test')") return true except: plpy.notice('the constraint was violated') return false $$language 'plpythonu'; where the insert violates a unique constraint and it never gets to the except. The function dies and doesn't get to my except with: WARNING: plpython: in function testme: DETAIL: : Unknown error in PLy_spi_execute_query ERROR: duplicate key violates unique constraint "survey_types_pkey" CONTEXT: SQL statement "insert into reports.survey_types(typeid,name)values(1,'test')" -- 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] Reusing cached prepared statement slow after 5 executions
Dean Rasheed wrote: >> I can confirm, when I call ps.setPrepareThreshold(1) the query is slow >> immediately, so the plan must be different with the server prepared >> statements. > > You can confirm that from psql by doing > > EXPLAIN ANALYSE SELECT ... ; > > and then > > PREPARE ps( ... ) AS SELECT ... ; > EXPLAIN ANALYSE EXECUTE ps ( ... ) ; > > using your query and the parameters in question. > > It is entirely possible that the plan chosen for the prepared > statement will be worse than the one used when the parameters are > known at planning time. The prepared statement doesn't know what > parameters are going to be used, so it can't always come up with the > best plan. See the notes in the PREPARE manual page: > http://www.postgresql.org/docs/9.0/static/sql-prepare.html Could the parameter cursor_tuple_fraction play a role here too? 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] An amusing MySQL weakness--not!
On Sunday 26. June 2011 16.11.06 Vincent Veyron wrote: > Le dimanche 26 juin 2011 à 00:05 -0700, Darren Duncan a écrit : > > Michael Nolan wrote: > > > > Having real BOOLEAN is just one of the reasons I like Postgres the most. > > Would you mind giving an example of where a boolean field would be a win > over an integer one? > > I'm asking this because I frequently wonder what is best for my use; I > normally query postgres via Perl modules, which don't care about boolean > (the driver converts t/f to 0/1), but I like to tune my fields properly. PHP has its own Boolean values TRUE/FALSE, but reads Postgresql Booleans as 't'/'f'. You always have to rely on kludgy konstructs like if ($pg_bool == 't') then $my_bool = TRUE; elseif ($pg_bool == 'f') then $my_bool = FALSE; else $my_bool = NULL; It's of course much easier to use integer values, but it sucks not to use a bool when you want a variable that can't be anything but TRUE, FALSE or NULL. It obfuscates the code to use a var that evaluates to an integer, but in reality is a Boolean in disguise. regards, Leif -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Custom types as parameter in stored function
Hello to everyone, I am trying to pass custom types as parameters in stored functions, and I tried this syntax successfully: create type myType as (id bigint, name character varying); create or replace myfunc(obj myType) returns void as begin ... end; select myfunc((1, 'foo')::myType; In this manner, if I understand it, there is a positional assignment of attribute value: id = 1 and name = foo. My ask is is there a manner to assing value to attribute of custom type by name instead by position. Thanks in advance. Mephysto. -- View this message in context: http://postgresql.1045698.n5.nabble.com/Custom-types-as-parameter-in-stored-function-tp4527618p4527618.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] Custom types as parameter in stored function
Ehmmm, sorry.. Correct syntax for select is: select myfunc((1, 'foo')::myType); -- View this message in context: http://postgresql.1045698.n5.nabble.com/Custom-types-as-parameter-in-stored-function-tp4527618p4527663.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] Reusing cached prepared statement slow after 5 executions
On 27 June 2011 07:50, Rob Gansevles wrote: > I can confirm, when I call ps.setPrepareThreshold(1) the query is slow > immediately, so the plan must be different with the server prepared > statements. > You can confirm that from psql by doing EXPLAIN ANALYSE SELECT ... ; and then PREPARE ps( ... ) AS SELECT ... ; EXPLAIN ANALYSE EXECUTE ps ( ... ) ; using your query and the parameters in question. It is entirely possible that the plan chosen for the prepared statement will be worse than the one used when the parameters are known at planning time. The prepared statement doesn't know what parameters are going to be used, so it can't always come up with the best plan. See the notes in the PREPARE manual page: http://www.postgresql.org/docs/9.0/static/sql-prepare.html Regards, Dean -- 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] Anyone using silent_mode?
On Mon, 2011-06-27 at 10:06 +0300, Heikki Linnakangas wrote: > Is anyone using silent_mode=on ? There's some discussion on > pgsql-hackers [1] on whether it should be removed altogether in 9.2, > since you can get the same functionality with "pg_ctl start", or nohup. > If you're using silent_mode, what are you using it for? > > [1] > http://archives.postgresql.org/message-id/1308926157-sup-7...@alvh.no-ip.org > Not using it. Never did, and won't. -- Guillaume http://blog.guillaume.lelarge.info http://www.dalibo.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] An amusing MySQL weakness--not!
Στις Sunday 26 June 2011 17:11:06 ο/η Vincent Veyron έγραψε: > Le dimanche 26 juin 2011 � 00:05 -0700, Darren Duncan a �crit : > > Michael Nolan wrote: > > > Having real BOOLEAN is just one of the reasons I like Postgres the most. > > > > Would you mind giving an example of where a boolean field would be a win > over an integer one? > > I'm asking this because I frequently wonder what is best for my use; I > normally query postgres via Perl modules, which don't care about boolean > (the driver converts t/f to 0/1), but I like to tune my fields properly. Alright, but in other enterprise-level platforms, like java, there is a boolean data type and a Boolean class wrapper. > > > -- > Vincent Veyron > http://marica.fr/ > Logiciel de gestion des sinistres et des contentieux pour le service juridique > > -- Achilleas Mantzios -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Anyone using silent_mode?
Is anyone using silent_mode=on ? There's some discussion on pgsql-hackers [1] on whether it should be removed altogether in 9.2, since you can get the same functionality with "pg_ctl start", or nohup. If you're using silent_mode, what are you using it for? [1] http://archives.postgresql.org/message-id/1308926157-sup-7...@alvh.no-ip.org -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general