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
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
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
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
"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
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
"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
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
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
"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
(
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
"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
"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:
> 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:
> 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
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_
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
"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
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
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
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
21 matches
Mail list logo
