Hello.
I use swedish locale
show lc_numeric;
lc_numeric
-
sv_SE.UTF-8
and I get a . (dot) in all floating-point numbers.
This makes me wonder, when can I see the effects of the locale? That is, I get
select 355/113.0 as pie;
pie
3,1415929203539823
Hi list,
In Oracle I can...
create table a
(
b varchar2(10 chars)
);
...and then, regardless of character encoding and how much space an
ascii character vs a ö takes, 10 characters will fit there.
If I do say a web-thing in php I have to do horrors like...
if (10 < mb_strlen ($b, '8bit'))
{
On 21/09/10 10:40, Marcus Engene wrote:
Hi list,
In Oracle I can...
create table a
(
b varchar2(10 chars)
);
...and then, regardless of character encoding and how much space an
ascii character vs a ö takes, 10 characters will fit there.
Is there anything I've misunderstood? How does the rest
I recommend to use TEXT as type for that kind of columns.
99 out of 100 theories about "this value will never be longer then xx
characters" fail in the long run.
And "text", limited only by PostgreSQLs limits, performs as good or
better then varchar(length_limit) The time of "we only can allow n
c
On Tuesday, September 21, 2010 07:23:45 Massa, Harald Armin wrote:
> I recommend to use TEXT as type for that kind of columns.
> 99 out of 100 theories about "this value will never be longer then xx
> characters" fail in the long run.
>
> And "text", limited only by PostgreSQLs limits, performs as
On 9/21/10 1:29 , Terry Lee Tucker wrote:
On Tuesday, September 21, 2010 07:23:45 Massa, Harald Armin wrote:
I recommend to use TEXT as type for that kind of columns.
99 out of 100 theories about "this value will never be longer then xx
characters" fail in the long run.
And "text", limited
On Mon, Sep 20, 2010 at 10:06 AM, Willy-Bas Loos wrote:
Rows are sent back in the entireity, so the PG instance would need
enough memory to work with that row. When you're running a 32bit
version of PG, values whose size is beyond ~100MB are a bit touch and go
whether it will
On Tue, Sep 21, 2010 at 1:23 PM, Massa, Harald Armin wrote:
> I recommend to use TEXT as type for that kind of columns.
> 99 out of 100 theories about "this value will never be longer then xx
> characters" fail in the long run.
>
> And "text", limited only by PostgreSQLs limits, performs as good
We are using 7.4.13 and run the pg_autovacuum. Over the years, the
database has grown so our maintenance plan was to "move" everything
except for the last year. Since the server is kept up always using a
full vacuum is out of the question. However the space is running out
and we tried insta
try reindex database;
and move away from 7.4, it is unsupported, and ancient history.
--
GJ
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Arjen,
> You do need to be wary of malicious users who put a first name of a
>few hundred megabytes.
yes, but if that "my first name is a video" hits the database, it is
allready to late, isn't it?
If it is open to the public, input should be sanitized WAY earlier;
and for an internal applicatio
Dear all,
I have a single "source" table that is referenced by six
specialization tables, which include:
"journal_article"
"report"
4 more
There is a "citation" column in the source, which is what will be
displayed to users. This is generated by a trigger function on each
specialization table
Hello,
I have developed an application in C++ under Qt in Windows XP, now I would
like
to port it to Ubuntu GNU/Linux.
Choosing the libraries in Windows was a piece of cake: the bottom of my Qt
qmake project file was
win32 {
LIBS += "C:\Progra~1\PostgreSQL\8.4\lib\libpq.lib"
INCLUDEPA
A B writes:
> I use swedish locale
> show lc_numeric;
> lc_numeric
> -
> sv_SE.UTF-8
> and I get a . (dot) in all floating-point numbers.
The regular output of numbers is intentionally not locale-aware.
You can use to_char() to obtain locale-specific formats.
Henri De Feraudy wrote:
> linux-g++ {
> LIBS += /usr/lib/libpq.a
>INCLUDEPATH += /usr/include/postgresql
> }
Try:
linux-g++ {
LIBS += -lpq
INCLUDEPATH += /usr/include/postgresql
}
Also make sure that you have the libpq-dev package installed.
Best regards,
--
Daniel
Pos
On Mon, Sep 20, 2010 at 6:23 PM, Tatsuo Ishii wrote:
> I have used PostgreSQL 9.0 + pgpool-II 3.0 and they work fine with md5
> auth. Your log seems to indicate that the password in pool_passwd and
> the one in pg_shadow are not identical. Can you verify that?
> The query result:
>
> select pass
> Hey Stefan,
>
> The sounds like you have a field "id" in you "c_transactions" without
> default value (which usually should be nextval('some_sequence'::regclass).
> Do you create a sequence for "c_transactions"."id" ?
>
Hi Dmitriy,
yes it's right, the id column does not have a default value
On Tue, Sep 21, 2010 at 10:26 AM, Bryan Murphy wrote:
> On Mon, Sep 20, 2010 at 6:23 PM, Tatsuo Ishii wrote:
>
>> I have used PostgreSQL 9.0 + pgpool-II 3.0 and they work fine with md5
>> auth. Your log seems to indicate that the password in pool_passwd and
>> the one in pg_shadow are not identi
On Tue, 2010-09-21 at 20:39 +0800, Christopher Gorge A. Marges wrote:
> We are using 7.4.13 and run the pg_autovacuum. Over the years, the
> database has grown so our maintenance plan was to "move" everything
> except for the last year. Since the server is kept up always using a
> full vacuum is
At 11:46 AM 8/24/2010, Craig Ringer wrote:
On 24/08/2010 11:06 AM, A.M. wrote:
On Aug 23, 2010, at 10:18 PM, Craig Ringer wrote:
On 08/24/2010 06:43 AM, Bruce Momjian wrote:
A.M. wrote:
There is a new pg_notify function in pgsql 9.0 but no pg_listen
equivalent? Why? It sure would be handy t
On Tue, Sep 21, 2010 at 10:45 AM, Bryan Murphy wrote:
> I'm sorry, when I went back over to double check my steps I realized I ran
> the wrong command. I am *still* having the problem. It appears that the
> MD5 hashes now match, but it's still failing. I have postgres and pgpool
> installed in
Okay, we're finally getting the last bits of corruption fixed, and I finally
remembered to ask my boss about the kill script.
The only details I have are these:
1) The script does nothing if there are fewer than 1000 locks on tables in
the database
2) If there are 1000 or more locks, it will gra
Lincoln Yeoh writes:
> To me what would also be useful would be synchronous notifications.
AFAICS this exists already --- or if it doesn't, that's a client-library
deficiency, not something to solve by inventing more SQL functions.
The form you propose cannot work anyway since NOTIFY events are n
On Tuesday 21 September 2010, Henri De Feraudy elucidated thus:
> Hello,
> I have developed an application in C++ under Qt in Windows XP, now I
> would like to port it to Ubuntu GNU/Linux.
> Choosing the libraries in Windows was a piece of cake: the bottom of
> my Qt qmake project file was
> win3
On 21 Sep 2010, at 16:13, William Temperley wrote:
> Dear all,
>
> I have a single "source" table that is referenced by six
> specialization tables, which include:
> "journal_article"
> "report"
> 4 more
>
> e.g.:
> """
> update source set citation = get_report_citation(
>(select source
On Tue, Sep 21, 2010 at 12:57 PM, Sam Nelson wrote:
>> On Thu, Sep 9, 2010 at 8:14 AM, Merlin Moncure wrote:
>> Naturally people are going to be skeptical of ec2 since you are so
>> abstracted from the hardware. Maybe all your problems stem from a
>> single explainable incident -- but we definit
On 21 September 2010 18:39, Alban Hertroys
wrote:
> On 21 Sep 2010, at 16:13, William Temperley wrote:
>
>> Dear all,
>>
>> I have a single "source" table that is referenced by six
>> specialization tables, which include:
>> "journal_article"
>> "report"
>> 4 more
>>
>> e.g.:
>> """
>> update
"Frank Ch. Eigler" wrote
Subject: Re: Getting FATAL: terminating connection due to administrator command
Date: 16.09.2010 22:59
>
>Peter Hopfgartner writes:
>
>> [...]
>> > >http://sourceware.org/systemtap/examples/process/sigmon.stp
>
>> Now we had the error, but systemtap did n
Ok I found the solution. I have to use the UPDATE command and not the INSERT:
UPDATE c_transactions SET timestamp = entrytimestamp
and than:
UPDATE c_transactions SET timestamp = exittimestamp WHERE exittimestamp IS NOT
NULL
--
Sent via pgsql-general mailing list (pgsql-general@postgres
Hey Stefan,
For surrogate keys there is no reason to calculate values manually.
You should use sequences instead. Please, see
http://www.postgresql.org/docs/8.3/static/sql-createsequence.html
You may also use a SERIAL data type which creates a sequence
for you automatically upon its creation. Plea
hey all,
I think versioned pl/[pgsql|python|perl|bash|java] functions would be
a great addition to 9.1. Imagine that instead of CREATE OR REPLACE
FUNCTION you could do CREATE AND VERSION FUNCTION and then all
modifications to the function could be versioned so that you could
revert/rollback to a s
Yesterday, I had twelve thousand "cache lookup failed for type N"
messages, like this:
2010-09-20 00:00:00 PDT ERROR: cache lookup failed for type 14237017
2010-09-20 00:00:00 PDT CONTEXT: SQL statement "INSERT INTO
mycluster.sl_log_2 (log_origin, log_xid, log_tableid, log_actionseq,
log_cmdtyp
OK, I'm a bit confused now. So it's not a race condition (i.e. a bug) in
a pg_relation_size but a feature?
Well, "feature" is in the eye of the beholder I guess. The race
condition is not really avoidable; certainly pg_relation_size() can't
do anything to prevent it. And you do *not* want "gua
On Tue, 2010-09-21 at 14:56 -0500, Rhys A.D. Stewart wrote:
> hey all,
>
> I think versioned pl/[pgsql|python|perl|bash|java] functions would be
> a great addition to 9.1. Imagine that instead of CREATE OR REPLACE
> FUNCTION you could do CREATE AND VERSION FUNCTION and then all
> modifications to
Hi,
Just looking around 9.0 and noticed pg_database is missing the
datconfig field which stored default session info for the database.
Where is this stored now? I looked in the release notes, but no mention
of datconfig.
Thanks,
Tony
--
Sent via pgsql-general mailing list (pgsql-general@p
2010/9/21 Joshua D. Drake :
> On Tue, 2010-09-21 at 14:56 -0500, Rhys A.D. Stewart wrote:
>> hey all,
>>
>> I think versioned pl/[pgsql|python|perl|bash|java] functions would be
>> a great addition to 9.1. Imagine that instead of CREATE OR REPLACE
>> FUNCTION you could do CREATE AND VERSION FUNCTIO
On Dienstag, 21. September 2010, Aleksey Tsalolikhin wrote:
> Yesterday, I had twelve thousand "cache lookup failed for type N"
> messages, like this:
> What does "type 14237017" mean?
pg_type oid
> What cache are we talking about?
Did you alter a type before?
There's a bug in postgres, tha
Le 21/09/2010 23:04, Tony Caduto a écrit :
> Hi,
> Just looking around 9.0 and noticed pg_database is missing the
> datconfig field which stored default session info for the database.
> Where is this stored now? I looked in the release notes, but no mention
> of datconfig.
>
You should look in
Hey all,
After ten years with stored procedures I am thinking so this is not
> too well technique. Much better is writing stored procedures to a file
> and using usual tools for file's versioning. We did some tools for
> storing a versions inside database, but still we prefer a standard
> develope
On Tue, Sep 21, 2010 at 2:06 PM, Jens Wilke wrote:
> On Dienstag, 21. September 2010, Aleksey Tsalolikhin wrote:
>> Yesterday, I had twelve thousand "cache lookup failed for type N"
>> messages, like this:
>
>> What does "type 14237017" mean?
>
> pg_type oid
Dear Jens,
I am trying to understa
On Dienstag, 21. September 2010, Aleksey Tsalolikhin wrote:
Hi Aleksey,
> So PostgreSQL was trying to lookup a row in a system table and
> did not find it in a cache.
yes,
select * from pg_type where oid =14237017
>> Did you alter a type before?
> No. I don't even know how to alter a type.
Sam Nelson writes:
> Okay, we're finally getting the last bits of corruption fixed, and I finally
> remembered to ask my boss about the kill script.
> The only details I have are these:
> 1) The script does nothing if there are fewer than 1000 locks on tables in
> the database
> 2) If there are
On Tuesday 21 September 2010, Dmitriy Igrishin elucidated thus:
> Hey all,
>
> After ten years with stored procedures I am thinking so this is not
>
> > too well technique. Much better is writing stored procedures to a
> > file and using usual tools for file's versioning. We did some tools
> > for
Is there anything like a macro or an inline table valued function in postgres?
i.e I define a query as a function/macro and reuse the function in queries and
the dbms will expand the function/macro to its definition, thus avoiding any
overhead.
If not what is the closest thing?
Thanks
On Tue, Sep 21, 2010 at 3:10 PM, Jens Wilke wrote:
> On Dienstag, 21. September 2010, Aleksey Tsalolikhin wrote:
>
>> So PostgreSQL was trying to lookup a row in a system table and
>> did not find it in a cache.
>
> yes,
> select * from pg_type where oid =14237017
Thank you.
>>> Did you alter
> On Tue, Sep 21, 2010 at 10:45 AM, Bryan Murphy wrote:
>
>> I'm sorry, when I went back over to double check my steps I realized I ran
>> the wrong command. I am *still* having the problem. It appears that the
>> MD5 hashes now match, but it's still failing. I have postgres and pgpool
>> insta
On Tue, Sep 21, 2010 at 5:12 PM, Pavel Stehule wrote:
> 2010/9/21 Joshua D. Drake :
>> On Tue, 2010-09-21 at 14:56 -0500, Rhys A.D. Stewart wrote:
>>> hey all,
>>>
>>> I think versioned pl/[pgsql|python|perl|bash|java] functions would be
>>> a great addition to 9.1. Imagine that instead of CREATE
Bret Green writes:
> Is there anything like a macro or an inline table valued function in
> postgres?
Recent versions can inline SQL-language functions, if they consist of
a simple SELECT and meet a few other constraints. I think the main
nonobvious constraint is they should be marked STABLE a
On Tue, Sep 21, 2010 at 8:08 PM, Tatsuo Ishii wrote:
> Unfortunately the gdb backtrace does not show enough information
> because of optimization, I guess. Can you take a backtrace with
> optimization disabled binary?
>
> You can obtain this by editing Makefile around line 147.
>
>
I edited conf
Uh, is there a way around this problem?
$ bin/pg_upgrade -c -d /usr/local/pgsql-8.4/data -D data -b
/usr/local/pgsql-8.4/bin -B bin
Performing Consistency Checks
-
Checking old data directory (/usr/local/pgsql-8.4/data) ok
Checking old bin directory (/usr/local/pgs
But how would the newer version prevent bloat and eliminate making the
database unavailable while the *maintenance* goes on?
The database is more than five years old, and we did not delete records
until recently and when we do delete them, naturally the records are in
front of the table and t
Karl Denninger wrote:
> Uh, is there a way around this problem?
>
> $ bin/pg_upgrade -c -d /usr/local/pgsql-8.4/data -D data -b
> /usr/local/pgsql-8.4/bin -B bin
> Performing Consistency Checks
> -
> Checking old data directory (/usr/local/pgsql-8.4/data) ok
> Chec
On 9/21/2010 10:16 PM, Bruce Momjian wrote:
> Karl Denninger wrote:
>> Uh, is there a way around this problem?
>>
>> $ bin/pg_upgrade -c -d /usr/local/pgsql-8.4/data -D data -b
>> /usr/local/pgsql-8.4/bin -B bin
>> Performing Consistency Checks
>> -
>> Checking old dat
Karl Denninger writes:
> $ more tables_using_reg.txt
> Database: marketticker
> public.pg_ts_dict.dict_init
> public.pg_ts_dict.dict_lexize
> public.pg_ts_parser.prs_start
> public.pg_ts_parser.prs_nexttoken
> public.pg_ts_parser.prs_end
> public.pg_ts_parser.prs_headline
> public.p
On Tue, Sep 21, 2010 at 9:10 PM, Christopher Gorge A. Marges
wrote:
> But how would the newer version prevent bloat and eliminate making the
> database unavailable while the *maintenance* goes on?
>
> The database is more than five years old, and we did not delete records
> until recently and when
I have been trying to install the Gevel module but am getting an error when
running make on the gevel files download.
The error is:
/contrib/contrib-global.mk: No such file or directory.
I have also tried USE_PGXS=1 make, but get the same result. I am unable to
find contrib-global.mk.
I have
56 matches
Mail list logo
