Hi,
On Wednesday 29 March 2006 07:32, [EMAIL PROTECTED] wrote:
> Hi
>
> We are trying to fetch records from Postgre Tables.
>
> We are successfully able to build connectivity. We are Using Postgre ODBC
> Driver (Unicode).
>
> But when I query the tables of Postgre it is unable to map the datatype
On Wed, 2006-03-29 at 11:02 +0530, [EMAIL PROTECTED] wrote:
> CAUSE DETERMINATION
>
> VARCHAR datatype from PostgreSQL is translated by your ODBC driver in
> an unsupported datatype for HSODBC.
>
>
> CAUSE JUSTIFICATION
>
> In the trace file, you ge
Hi
Thansk you very much for the inforamtion.
We tried Postgres ODBC Driver (ANSI. Now we can view the datatype
varchar/text.
But since there is a limitation
of Ascii character set, we are unable to view Latvian Specific characters.
If you have any idea about this,
please let me know.
Thanks &
> Thansk you very much for the inforamtion. We tried Postgres ODBC Driver
> (ANSI. Now we can view the datatype varchar/text.
>
> But since there is a limitation of Ascii character set, we are unable to
> view Latvian Specific characters.
>
> If you have any idea about this, please let me know
Pg-Hackers,I'm having the following issue:create table aluno (id serial, nome varchar(60));rodrigo=# select * from aluno order by nome offset 35 limit 5; id | nome+---
36 | GABRIELA HELEDA DE SOUZA 37 | GABRIELA JACOBY NOS 38 | GABRIEL ALCIDES KLIM
> Thansk you very much for the inforamtion. We tried Postgres ODBC Driver
> (ANSI. Now we can view the datatype varchar/text.
>
> But since there is a limitation of Ascii character set, we are unable to
> view Latvian Specific characters.
>
> If you have any idea about this, please let me know
Here's my configuration which works just fine (using unixODBC). The
postgres database was created UTF-8.
Software:
- SuSE 10
- PostgreSQL 8.1.3
- Oracle10g XE
- psqlODBC 07.03.0260 (make sure to compile --with-unixODBC)
- unixODBC 2.2.11
My /etc/unixODBC/odbcinst.ini:
[PostgreSQL]
Description =
I don't think PostgreSQL's sorting it wrong... here's the output of
Linux's sort utility:
[EMAIL PROTECTED]:~> cat test.txt
GABRIEL ALEXANDRE DA SILVA MANICA
GABRIELA LETICIA BATISTA NUNES
GABRIEL ALCIDES KLIM PERONDI
GABRIELA JACOBY NOS
GABRIELA HELEDA DE SOUZA
[EMAIL PROTECTED]:~> cat test.txt
Yeah, I think there's a problem on Linux locales.Using the C locale, it works as expected:[EMAIL PROTECTED]:~$ export LC_ALL=C && cat test.txt | sortGABRIEL ALCIDES KLIM PERONDIGABRIEL ALEXANDRE DA SILVA MANICA
GABRIELA HELEDA DE SOUZAGABRIELA JACOBY NOSGABRIELA LETICIA BATISTA NUNESBut when using
"Rodrigo Hjort" <[EMAIL PROTECTED]> writes:
> The fact is that I can't raise PostgreSQL with C encoding, as special
> characters are used on most tables.
You're confusing locale and encoding, which are two different (though
interrelated) things.
I suspect the right choice for you will be to use C
Hi,
As we know, index vacuum could be sped up significantly if it didn't have
to lock every page in left to right direction because of the integrity issue
described in nbtree/README. We could then scan the index in physical
order, and AFAICS combine the btbulkdelete and btvacuumcleanup logic t
Thanks all. I'm gonna try other locales and encodings.2006/3/29, Tom Lane <[EMAIL PROTECTED]>:
"Rodrigo Hjort" <[EMAIL PROTECTED]> writes:> The fact is that I can't raise PostgreSQL with C encoding, as special> characters are used on most tables.
You're confusing locale and encoding, which are two
Folks,
I'm trying to get pg_service.conf working on Windows so we can
standardize on a way of doing things cross-platform, and noticed that
pg_config.exe --configure
doesn't report anything by way of --sysconfdir, which in turn means
that people have to do some fragile hackery in order even to s
David Fetter wrote:
Folks,
I'm trying to get pg_service.conf working on Windows so we can
standardize on a way of doing things cross-platform, and noticed that
pg_config.exe --configure
why are you using this flag? if you leave it off you will see everything.
doesn't report anything by
Hi all,
i would like to work on control setting pg_hba.conf via SQL( cf TODO
List ), and i would know if the pg_hda.conf must be replaced by pg_hba
table ?
Emmanuel BERTHOULE
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner
On Wed, 2006-03-29 at 21:48 +0300, Heikki Linnakangas wrote:
> As we know, index vacuum could be sped up significantly if it didn't
> have
> to lock every page in left to right direction because of the integrity
> issue
> described in nbtree/README. We could then scan the index in physical
> or
I'd like to expand this idea with this TODO item. If this is already
on the TODO, please disregard. I'm thinking something like the
following:
Enable the alteration and persistence of postgresql.conf and
pg_hba.conf configuration parameters via SQL.
On 3/29/06, BERTHOULE Emmanuel <[EMAIL PROTE
ISTM that the first requirement is for a sane API that will handle the
fact that HBA lines are ordered. Persistence in itself shouldn't be a
big problem - we already do that with some shared tables, iirc.
so we might have some functions like:
insert_hba_rule(at_position int, connection_type
On 3/29/06, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
> ISTM that the first requirement is for a sane API that will handle the
> fact that HBA lines are ordered. Persistence in itself shouldn't be a
> big problem - we already do that with some shared tables, iirc.
I agree.
--
Jonah H. Harris, Dat
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> 1. Instead of stopping on the first matching tuple, scan the whole index
> page for all matching entries at once.
That loses the ability to reflect tuple deadness back into LP_DELETE
flags, no? Which is a problem already for bitmap indexscans, but
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> ISTM that the first requirement is for a sane API that will handle the
> fact that HBA lines are ordered. Persistence in itself shouldn't be a
> big problem - we already do that with some shared tables, iirc.
I'm a bit suspicious of proposals that we
On Wed, Mar 29, 2006 at 03:53:13PM -0500, Andrew Dunstan wrote:
> David Fetter wrote:
> >Folks,
> >
> >I'm trying to get pg_service.conf working on Windows so we can
> >standardize on a way of doing things cross-platform, and noticed
> >that
> >
> >pg_config.exe --configure
>
> why are you using t
On Wed, 2006-03-29 at 16:49 -0500, Tom Lane wrote:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> > 1. Instead of stopping on the first matching tuple, scan the whole index
> > page for all matching entries at once.
>
> That loses the ability to reflect tuple deadness back into LP_DELETE
> fl
On Wed, 29 Mar 2006 08:46 am, Philip Yarra wrote:
> OK, how about on \d+, if the object is not on pg_default or pg_global,
> print the tablespace that this object is on? That way, people not using
> tablespaces won't ever see it.
Tom, does this answer your objection? If so, I'll produce a patch fo
Hi folks, I've found that CVS HEAD psql's \c doesn't quite behave as expected
when postmaster is listening on non-default port. In this case I have
postmaster listening on port 5434:
[EMAIL PROTECTED] pgsql]$ /usr/local/pgsql-cvs-head/bin/psql -p5434 -dpyarra
Welcome to psql 8.2devel, the Postgr
David Fetter wrote:
doesn't report anything by way of --sysconfdir, which in turn means
that people have to do some fragile hackery in order even to see a
pg_service.conf file. Can we put such a configuration directive
into the binary builds? Is this known to work?
In any case, the d
>> Which is good. But I've got big trouble to login to this initial db by
>> using this auto-created username "postgres" through pgAdmin:((( The first
>>try failed due to "Ident authentication failed", so I follow the suggestion
>>on the pop-up window of pgAdmin3, and changed the ident method in
On Wednesday 29 March 2006 17:04, Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > ISTM that the first requirement is for a sane API that will handle the
> > fact that HBA lines are ordered. Persistence in itself shouldn't be a
> > big problem - we already do that with some shared
-hackers is not the place for these questions. Please ask your questions
in the correct forum, possibly pgsql-general. -hackers is for discussion
of backend development.
cheers
andrew
lmyho wrote:
Which is good. But I've got big trouble to login to this initial db by
using this auto-crea
Philip Yarra <[EMAIL PROTECTED]> writes:
> Hi folks, I've found that CVS HEAD psql's \c doesn't quite behave as
> expected
Yeah, there were complaints about this already. I think the problem was
introduced by this patch:
2006-02-11 21:54 momjian
* doc/src/sgml/ref/psql-ref.sgml, src/b
On Wed, Mar 29, 2006 at 10:19:51PM -0500, Tom Lane wrote:
> Philip Yarra <[EMAIL PROTECTED]> writes:
> > Hi folks, I've found that CVS HEAD psql's \c doesn't quite behave as
> > expected
>
> Yeah, there were complaints about this already. I think the problem was
> introduced by this patch:
I se
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
ISTM that the first requirement is for a sane API that will handle the
fact that HBA lines are ordered. Persistence in itself shouldn't be a
big problem - we already do that with some shared tables, iirc.
I'm a bit suspicio
Andrew Dunstan wrote:
>
> ISTM that the first requirement is for a sane API that will handle the
> fact that HBA lines are ordered. Persistence in itself shouldn't be a
> big problem - we already do that with some shared tables, iirc.
>
> so we might have some functions like:
>
> insert_hba_rul
Just to let you guys know, I spoke to Microsoft and they confirmed that
they have restricted access to the 'nul' device in a security update (to
admin users). Not quite sure of the extact update! This is hardcoded in
the Windows source, so no way to change somthing via code :(
- James
-Ori
On Wed, 2006-03-29 at 16:20 -0500, Jonah H. Harris wrote:
> Enable the alteration and persistence of postgresql.conf and
> pg_hba.conf configuration parameters via SQL.
Agreed.
I'd also add the seemingly obvious caveat that parameters should be
unique. A common problem is for one person to edit
35 matches
Mail list logo
