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 get the
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.
I'm
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 SOUZA37 | GABRIELA JACOBY NOS38 | GABRIEL ALCIDES KLIM PERONDI39 |
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
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
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
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
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
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
order,
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
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,
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,
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 I
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 move
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 this flag? if you
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
flags, no?
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 for
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
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
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 the
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 tables,
-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
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,
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 sent one
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
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:
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
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 a
34 matches
Mail list logo
