Bruce Momjian написа:
Milen A. Radev wrote:
Tom Lane ??:
"Dmitry Ryabov" writes:
Description:Incorrect log_line_prefix default value in
postgresql.conf
log_line_prefix = '%%t '
(must be log_line_prefix = '%t ')
Uh, the default setting is an empty string. Are you sure this is
not
Milen A. Radev wrote:
> Tom Lane ??:
> > "Dmitry Ryabov" writes:
> >> Description:Incorrect log_line_prefix default value in
> >> postgresql.conf
> >
> >> log_line_prefix = '%%t '
> >> (must be log_line_prefix = '%t ')
> >
> > Uh, the default setting is an empty string. Are you sure
Tom Lane написа:
"Dmitry Ryabov" writes:
Description:Incorrect log_line_prefix default value in
postgresql.conf
log_line_prefix = '%%t '
(must be log_line_prefix = '%t ')
Uh, the default setting is an empty string. Are you sure this is
not your own error? If it isn't, perhaps it
"Dmitry Ryabov" writes:
> Description:Incorrect log_line_prefix default value in
> postgresql.conf
> log_line_prefix = '%%t '
> (must be log_line_prefix = '%t ')
Uh, the default setting is an empty string. Are you sure this is
not your own error? If it isn't, perhaps it is a problem in
Dmitry Ryabov wrote:
>
> The following bug has been logged online:
>
> Bug reference: 4861
> Logged by: Dmitry Ryabov
> Email address: dmitry-rya...@mail.ru
> PostgreSQL version: 8.4rc1
> Operating system: Windows
> Description:Incorrect log_line_prefix default value
The following bug has been logged online:
Bug reference: 4861
Logged by: Dmitry Ryabov
Email address: dmitry-rya...@mail.ru
PostgreSQL version: 8.4rc1
Operating system: Windows
Description:Incorrect log_line_prefix default value in
postgresql.conf
Details:
log_line_
"Obe, Regina" writes:
> If you have an index on a function that calls another function where the
> function being called does not have the namespace specifically prefixed.
This has nothing to do with either indexes or pg_dump. A function that
calls another function, or references a table, or do
> Hum. So the immediate problem is that st_transform() is failing to
> schema-qualify its reference to spatial_ref_sys. Think you need to
> be filing that one against PostGIS, not us.
Yah was sort of thinking that.
Though what about this -- isn't this case a bit more common
http://postgis.re
"Obe, Regina" writes:
> I tried with a simpler db and this is what I get
> pg_restore: [archiver (db)] could not execute query: ERROR: relation
> "spatial_ref_sys" does not exist
> LINE 1: SELECT proj4text FROM spatial_ref_sys WHERE srid = 4326 LIMI...
> ^
> QUERY:
"Kevin Grittner" writes:
> It's used in an example in 34.4.2 without a lot of definition. From
> experimenting a bit, it appears that when referencing a composite data
> value, any function which can take as its only parameter an instance
> of that composite type can be used as though it were a f
Okay seems to be a sequencing problem. Sorry I should have been paying
attention to the screen notices.
I tried with a simpler db and this is what I get
QUERY: SELECT proj4text FROM spatial_ref_sys WHERE srid = 4326 LIMIT 1
Command was: CREATE INDEX assets_building_idx_the_geom_4326 ON bui
"Obe, Regina" writes:
> Your example seems to work fine for me too. I'm trying to figure out the
> best way to give an isolated case without requiring you install a bunch of
> stuff.
Well, the only two possibilities for an index not being restored are
(1) it's not listed in the dump file, or
(
Tom,
Your example seems to work fine for me too. I'm trying to figure out the best
way to give an isolated case without requiring you install a bunch of stuff.
The only thing I can think of that is different about my case.
Is one its using a gist index instead of btree
and my operator classes
Tom Lane wrote:
> Look under "computed fields" in the index ... looks like it's
> towards the bottom of 34.4.2 in the 8.3 docs.
> http://www.postgresql.org/docs/8.3/static/xfunc-sql.html#AEN40267
>
> I had thought it was mentioned somewhere in chapter 4 as well, but
> am not seeing it there ri
"Regina" writes:
> If I have a functional index in place in a table in non-public schema that
> uses a function in public schema, these indexes never get restored.
Works for me (per attached). Please provide a *complete* example and
not an abstraction.
regards, tom lane
The following bug has been logged online:
Bug reference: 4860
Logged by: Regina
Email address: robe@cityofboston.gov
PostgreSQL version: 8.4rc1
Operating system: Windows
Description:Indexes gone after restore
Details:
This I think is an issue with prior versions
"Kevin Grittner" writes:
> Tom Lane wrote:
>> Per the fine manual, sp.count is another way of writing count(sp).
> Wow, that seems a horrid kludge. Is the standard responsible for that
> one, or is it a PostgreSQL extension?
Actually, we inherited that from PostQUEL. It's not in the standar
Tom Lane wrote:
> Per the fine manual, sp.count is another way of writing count(sp).
Wow, that seems a horrid kludge. Is the standard responsible for that
one, or is it a PostgreSQL extension?
Could you point me at where in the fine manual this is covered? I've
never stumbled across it in
On Thu, Jun 18, 2009 at 10:03:21AM -0400, Tom Lane wrote:
> hubert depesz lubaczewski writes:
> > # create table sold_products (items int4, product_id int4);
> > # create table products (id int4, codename text);
> > # select sp.count, p.codename from sold_products sp join products p on
> > sp.pro
hubert depesz lubaczewski writes:
> # create table sold_products (items int4, product_id int4);
> # create table products (id int4, codename text);
> # select sp.count, p.codename from sold_products sp join products p on
> sp.product_id = p.id;
> shown error:
> ERROR: column "p.codename" must a
Hi,
I tested it on 8.3.7 and on 8.4, but it doesn't seem to be version
bound.
steps to reproduce:
# create table sold_products (items int4, product_id int4);
# create table products (id int4, codename text);
# select sp.count, p.codename from sold_products sp join products p on
sp.product_id = p
21 matches
Mail list logo
