Joe Conway writes:
> Should I also be looking to replace all (or most) other instances of
> PQsetdbLogin()?
I think we at least wanted to fix pg_dump(all)/pg_restore. Not sure if
the others are worth troubling over.
regards, tom lane
--
Sent via pgsql-bugs mailing list
On 02/02/2010 10:08 PM, Tom Lane wrote:
> Joe Conway writes:
>> Are there any of the psql parameters that we do not want to allow to be
>> overridden by the conninfo string?
>
> Actually, now that I think about it, psql shouldn't be setting
> application_name at all. It should be setting
> fallb
Joe Conway writes:
> Are there any of the psql parameters that we do not want to allow to be
> overridden by the conninfo string?
Actually, now that I think about it, psql shouldn't be setting
application_name at all. It should be setting
fallback_application_name, and I think that should be aft
On 02/02/2010 06:40 PM, Tom Lane wrote:
> The difference with PQconnectdbParams is that the dbname might not be
> the first thing in the parameter array. I think that a straightforward
> implementation would have the effect of the expanded dbname overriding
> parameters given before it, but not th
On 2010-02-02, Tom Lane wrote:
> Jasen Betts writes:
>> jasen=# update member set id=id where id=441;
>> UPDATE 1
>> jasen=# create index member_search on member using gin (
>> (get_search_text_internal(member)) );
>> CREATE INDEX
>> jasen=# update member set id=id where id=441;
>> ERROR: table
Hello,
usually sql identifiers are case insensitive. There are exception. If
you use double quotes for sql identifier, then you have to write exact
same identifier everywhere.
postgres=# create table Foo(a integer);
CREATE TABLE
Time: 174,078 ms
postgres=# select * from Foo;
a
---
(0 rows)
Time
On Tue, Feb 2, 2010 at 12:11 PM, Kelly SACAULT wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5308
> Logged by: Kelly SACAULT
> Email address: kelly.saca...@gmail.com
> PostgreSQL version: 8.4.2
> Operating system: Ubuntu 9.10
> Description: How
The following bug has been logged online:
Bug reference: 5308
Logged by: Kelly SACAULT
Email address: kelly.saca...@gmail.com
PostgreSQL version: 8.4.2
Operating system: Ubuntu 9.10
Description:How to disable Case sensitivity on naming identifiers
Details:
I have in
Joe Conway writes:
> On 02/02/2010 06:10 PM, Tom Lane wrote:
>> We should also give more than zero thought to how values coming from the
>> expanded dbname should interact with values from other arguments to
>> PQconnectdbParams --- which should override which? And should there be
>> an order dep
On 02/02/2010 06:10 PM, Tom Lane wrote:
> Since we haven't yet released PQconnectdbParams, it's not too late
> to twiddle its API. What I'm thinking about is an additional
> boolean parameter "expand_dbname", which only if true would enable
> treating an equal-sign-containing dbname like a conninf
Fujii Masao writes:
> On Wed, Feb 3, 2010 at 10:05 AM, Joe Conway wrote:
>> Objections?
> I think that PQconnectdbParams() rather than psql should handle the
> dbname containing "=". Otherwise whenever we use PQconnectdbParams(),
> we would have to check for the content of the dbname before call
On 02/02/2010 05:59 PM, Tom Lane wrote:
> This seems bogus on a couple of levels. First off, I thought the idea
> was to get away from using PQsetdbLogin at all. If we go down this path
> we'll never be rid of it. Second, to preserve backwards compatibility
> we will have to duplicate this same
Joe Conway writes:
> If "=" is found in the dbname psql argument, the argument is assumed to
> be a conninfo string. In that case, append application_name to the
> conninfo and use PQsetdbLogin() as before. Otherwise use the new
> PQconnectdbParams().
This seems bogus on a couple of levels. Firs
On 02/02/2010 05:46 PM, Fujii Masao wrote:
> On Wed, Feb 3, 2010 at 10:05 AM, Joe Conway wrote:
>> Objections?
>
> I think that PQconnectdbParams() rather than psql should handle the
> dbname containing "=". Otherwise whenever we use PQconnectdbParams(),
> we would have to check for the content o
On Wed, Feb 3, 2010 at 10:05 AM, Joe Conway wrote:
> Here's a patch.
Thanks!
> If "=" is found in the dbname psql argument, the argument is assumed to
> be a conninfo string. In that case, append application_name to the
> conninfo and use PQsetdbLogin() as before. Otherwise use the new
> PQconne
On 02/01/2010 08:06 AM, Tom Lane wrote:
> Heikki Linnakangas writes:
>> Fujii Masao wrote:
>>> In HEAD, psql using conninfo fails in connecting to the server as follows.
>>>
>>> $ bin/psql "host=localhost"
>>> psql: FATAL: database "host=localhost" does not exist
>>>
>>> This is because the recen
Jasen Betts writes:
> jasen=# update member set id=id where id=441;
> UPDATE 1
> jasen=# create index member_search on member using gin (
> (get_search_text_internal(member)) );
> CREATE INDEX
> jasen=# update member set id=id where id=441;
> ERROR: table row type and query-specified row type do
Isaac Morland writes:
> I get the following warnings building 8.5alpha3 on Solaris 10.
> I do not get these warnings building 8.4 exactly the same way.
> standby.c:239: warning: int format, pid_t arg (arg 3)
> standby.c:247: warning: int format, pid_t arg (arg 5)
That looks like a real problem,
jasen=# update member set id=id where id=441;
UPDATE 1
jasen=# create index member_search on member using gin (
(get_search_text_internal(member)) );
CREATE INDEX
jasen=# update member set id=id where id=441;
ERROR: table row type and query-specified row type do not match
DETAIL: Physical storag
I get the following warnings building 8.5alpha3 on Solaris 10.
I do not get these warnings building 8.4 exactly the same way.
standby.c:239: warning: int format, pid_t arg (arg 3)
standby.c:247: warning: int format, pid_t arg (arg 5)
descriptor.c:23: warning: missing braces around initializer
des
On Sun, Jan 31, 2010 at 9:07 AM, Steve White wrote:
> Hi,
>
> I'm aware that this is a manifestation of the problem mentioned in the
> Caveats subsection of the Inheritance section. I want to emphasize it,
> and maybe rattle your cage a bit.
>
> I find the Postgres notion of inheritance very comp
"Igor Lasic" writes:
> We have an application running C-API stored procedures. After running for a
> while postgres crashes with:
> If I increase shared memory application runs longer but eventually crashes.
The odds are incredibly high that this means there's a memory-stomping
bug in your C sto
Igor Lasic wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5307
> Logged by: Igor Lasic
> Email address: i...@a-bb.net
> PostgreSQL version: 8.3.7
> Operating system: Linux
> Description:Crash in AllocSetAlloc
> Details:
>
> We have an applic
The following bug has been logged online:
Bug reference: 5307
Logged by: Igor Lasic
Email address: i...@a-bb.net
PostgreSQL version: 8.3.7
Operating system: Linux
Description:Crash in AllocSetAlloc
Details:
We have an application running C-API stored procedures. Aft
On Tue, Feb 2, 2010 at 7:38 AM, Tom Lane wrote:
> "" writes:
>> I made an installation of Postgres on a redhat machine after compiling
>> sources on a redhat machine. Everything is OK.
>> When i install Postgres on a debian machine, i get an error when using psql
>> : "psql: symbol lookup error:
"" writes:
> I made an installation of Postgres on a redhat machine after compiling
> sources on a redhat machine. Everything is OK.
> When i install Postgres on a debian machine, i get an error when using psql
> : "psql: symbol lookup error: /usr/lib/libreadline.so.5: undefined symbol:
> BC"
> I
The following bug has been logged online:
Bug reference: 5306
Logged by:
Email address: christophe.mou...@progimed.fr
PostgreSQL version: 8.4.1
Operating system: Linux/Redhat
Description:psql: symbol lookup error: /usr/lib/libreadline.so.5:
undefined symbol: BC
Detai
27 matches
Mail list logo
