Hi all, I’d like to use to_char function to return an already
formatted result set. The it_IT locale (correctly) specifies a numeric
group separator as “. ”, but I’d really want to use just “.”; not
standard but much more common.
Anyway, the problem is that I didn’t find enough about how to
Sorry, I forgot to say I am using version 8.2.6.
I already removed option -n and left only -s (sincer there are no
other user schemas in the db) and I get the same error.
However when I removed the -c option it worked fine!
And also when using a formatted dump it works ok (even with -c option)
Alvaro Herrera wrote:
Russ Brown escribió:
Masis, Alexander (US SSA) wrote:
SELECT CURRVAL(
pg_get_serial_sequence('my_tbl_name','id_col_name'));
Any reason why you can't just do this?
CREATE FUNCTION last_insert_id() RETURNS bigint AS $$
SELECT lastval();
$$ LANGUAGE SQL VOLATILE;
-Original Message-
Roberts, Jon [EMAIL PROTECTED] writes:
I am noticing a large number of temp schemas in my database. We use
temp tables but it doesn't appear that the schemas get dropped for
some
reason.
That's intentional. There doesn't seem a lot of value in dropping a
Magnus Hagander escribió:
Alvaro Herrera wrote:
Russ Brown escribió:
Masis, Alexander (US SSA) wrote:
SELECT CURRVAL(
pg_get_serial_sequence('my_tbl_name','id_col_name'));
Any reason why you can't just do this?
CREATE FUNCTION last_insert_id() RETURNS bigint AS $$
SELECT
On Fri, Aug 29, 2008 at 1:40 PM, Roberts, Jon [EMAIL PROTECTED] wrote:
Why have you got thousands of them? If you are running with thousands
of active backends, may I suggest a connection pooler?
I don't know. It looks like a bug to me where a temp table is created
and dropped on commit
On Fri, Aug 29, 2008 at 1:40 PM, Roberts, Jon
[EMAIL PROTECTED]
wrote:
Why have you got thousands of them? If you are running with
thousands
of active backends, may I suggest a connection pooler?
I don't know. It looks like a bug to me where a temp table is
created
and dropped on
Thanks Andrew.
On the server (the DB to be dumped) everything is UTF8.
On my home server (where I would like to mirror the DB), this is the output:
=# \l
List of databases
Name| Owner | Encoding
---+-+---
postgres | postgres
Tom Lane wrote:
Steve Clark [EMAIL PROTECTED] writes:
Tom Lane wrote:
Consider testing the conditions on A at the top level, instead of
redundantly checking them inside the sub-query on B.
Thanks for the response Tom, I am a SQL neophyte, so I'll try to
rework the query.
What I meant
On Fri, Aug 29, 2008 at 10:26:14PM +0800, Phoenix Kiula wrote:
Thanks Andrew.
On the server (the DB to be dumped) everything is UTF8.
On my home server (where I would like to mirror the DB), this is the output:
Hrm. Well, what about the locale, as I suggested? I have no idea if
it's
On 8/29/08, Andrew Sullivan [EMAIL PROTECTED] wrote:
Hrm. Well, what about the locale, as I suggested? I have no idea if
How should I check for the locale?
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
On Fri, Aug 29, 2008 at 11:12:35PM +0800, Phoenix Kiula wrote:
How should I check for the locale?
As the user that you issue the pg_dump with on the machine you
generated it, and as the user you're trying to use to restore the
data, at the command line type
$ locale
You end up with
On 29/08/2008 05:45, Tom Lane wrote:
A general comment on those pages is that the tabular lists of functions
are intended to give one-liner descriptions of what the functions do.
For cases where a one-liner isn't sufficient, there's a sentence or a
paragraph following the table.
I don't
On Friday 29 August 2008 8:12:35 am Phoenix Kiula wrote:
On 8/29/08, Andrew Sullivan [EMAIL PROTECTED] wrote:
Hrm. Well, what about the locale, as I suggested? I have no idea if
How should I check for the locale?
On Linux:
[EMAIL PROTECTED]:~$ locale
LANG=en_US.UTF-8
LANGUAGE=en
Thanks so much! I think we may be on to something:
On the pg_dump machine:
LANG=en_US.UTF-8
LC_CTYPE=en_US.UTF-8
LC_NUMERIC=en_US.UTF-8
LC_TIME=en_US.UTF-8
LC_COLLATE=en_US.UTF-8
LC_MONETARY=en_US.UTF-8
LC_MESSAGES=en_US.UTF-8
LC_PAPER=en_US.UTF-8
LC_NAME=en_US.UTF-8
LC_ADDRESS=en_US.UTF-8
On Fri, Aug 29, 2008 at 11:29:55PM +0800, Phoenix Kiula wrote:
So how can I change the locale on my local OSX machine? This could be
it. Thanks!
Before you start restoring, put a LANG environment variable. So
something like
LANG=en_US.UTF-8 psql
or else
LANG=en_US.UTF-8; export LANG
Tom Lane wrote:
[EMAIL PROTECTED] writes:
Thus, when piping the output (from legacy host 192.168.2.2) to
populate the newly initialized cluster, by way of running (on
the new
host 192.168.2.3)
pg_dumpall -h 192.168.2.2|psql
an error occurs in that first section when the
On Friday 29 August 2008 8:29:55 am Phoenix Kiula wrote:
Thanks so much! I think we may be on to something:
On the pg_dump machine:
LANG=en_US.UTF-8
LC_CTYPE=en_US.UTF-8
LC_NUMERIC=en_US.UTF-8
LC_TIME=en_US.UTF-8
LC_COLLATE=en_US.UTF-8
LC_MONETARY=en_US.UTF-8
LC_MESSAGES=en_US.UTF-8
On 8/30/08, Adrian Klaver [EMAIL PROTECTED] wrote:
Might also be useful to do SHOW ALL from within the database cluster you have
on your restore machine. Will show what choices initdb made.
test=# SHOW all;
Snip
lc_collate | en_US.UTF-8
lc_ctype
Hello all,
in which system tables can I find the effective run-time values of the
autovacuum configuration parameters...
naptime, thresholds, scale factors, etc
thx
joao
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
-- Original message --
From: Phoenix Kiula [EMAIL PROTECTED]
On 8/30/08, Adrian Klaver [EMAIL PROTECTED] wrote:
Might also be useful to do SHOW ALL from within the database cluster you
have
on your restore machine. Will show what choices initdb made.
Roberts, Jon [EMAIL PROTECTED] writes:
This is what I'm trying to understand. At what point does PostgreSQL
determine it needs to create a new temp schema versus reusing an
existing one? Maybe we are doing something incorrectly in our code.
They're associated with backends' slot numbers in a
Phoenix Kiula wrote:
Thanks Andrew.
On the server (the DB to be dumped) everything is UTF8.
On my home server (where I would like to mirror the DB), this is the output:
=# \l
List of databases
Name| Owner | Encoding
---+-+---
Hello
I have problem in my applications and don't know how to fix it.
This is the table and one of the indexes:
CREATE TABLE foo
(
id serial NOT NULL,
foo_name character varying(100),
realm_id integer
... and about 50 other columns
)
CREATE INDEX idx_foo_name_realm
ON foo
USING
If I have a series of RAISE NOTICE 'xxx' statements in a plpgsql
function and I call the function from pgAdmin the notice messages are
concatenated on a single line on the Messages tab. Is there any way to
get each message to appear on a separate line?
Is there a better way than using RAISE
I'm no expert at reading query plans, but I'm guessing the planner chose the
other plan because your offset + limit went beyond the row estimate.
Look's like it's then doing a disk based sort in the other plan which
probably explain why it's slow.
Someone please correct me if I'm wrong.
On Fri, Aug 29, 2008 at 4:38 PM, Oliver Weichhold [EMAIL PROTECTED] wrote:
Hello
I have problem in my applications and don't know how to fix it.
This is the table and one of the indexes:
CREATE TABLE foo
(
id serial NOT NULL,
foo_name character varying(100),
realm_id integer
The following SELECT INTO returns incorrect values in the variables
CATEGORY_NAME and PARENT_ID. If I copy the SELECT statement to pgAdmin,
delete the INTO clause and run the query it returns the correct values.
I am new to PostgreSQL and I must have something syntactically wrong in
the SELECT
Merlin Moncure [EMAIL PROTECTED] writes:
On Fri, Aug 29, 2008 at 4:38 PM, Oliver Weichhold [EMAIL PROTECTED] wrote:
Consider this query:
SELECT * FROM foo WHERE realm_id = 228 order by foo_name LIMIT 200 OFFSET
15000
try this:
SELECT * FROM foo WHERE realm_id = 228 order by realm_id,
Tom Lane wrote:
Maxim Boguk [EMAIL PROTECTED] writes:
[ ndistinct estimates way off ]
Estimating the number of distinct values in a distribution with a long
tail is just a really hard problem :-(
If I have a table where I know it has this property, is there
any way I can tell autovacuum's
Bill Todd [EMAIL PROTECTED] writes:
The following SELECT INTO returns incorrect values in the variables
CATEGORY_NAME and PARENT_ID. If I copy the SELECT statement to pgAdmin,
delete the INTO clause and run the query it returns the correct values.
You didn't show us the whole function
2008/8/29 Bill Todd [EMAIL PROTECTED]
If I have a series of RAISE NOTICE 'xxx' statements in a plpgsql function
and I call the function from pgAdmin the notice messages are concatenated on
a single line on the Messages tab. Is there any way to get each message to
appear on a separate line?
32 matches
Mail list logo
