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
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
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
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
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
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
-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
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
>> 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
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
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
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
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, 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
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
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
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
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
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
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
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
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
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
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
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
"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
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
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
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 =
> 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
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 &
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,
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
35 matches
Mail list logo
