On Monday 05 January 2004 12:51, Peter Eisentraut wrote:
> Jean-Eric Cuendet wrote:
> > - User permissions based on columns? (Ex: User1 has Select on Column
> > "CompayName" but User2 has update on column "CompanyName" while User3
> > has create new row on table).
>
> Well, I have about half a patc
On Saturday 10 January 2004 13:55, Shachar Shemesh wrote:
> Andreas Pflug wrote:
> > Sounds good. While I probably won't find time helping implementing the
> > driver; I have an OLEDB app running that currently uses
> > MSDASQL/psqlODBC. I'd certainly like testing your driver, and give
> > feedback
On Saturday 10 January 2004 19:16, Jon Jensen wrote:
> On Sat, 10 Jan 2004, Tom Lane wrote:
> > ISTM there are three fundamental problems with \d and friends:
> >
> > 1. Some people have a hard time remembering the commands.
> > 2. Some people aren't using psql.
> > 3. psql keeps breaki
I am going to Oregon tomorrow for 3 days, and will spend the rest of the
week in New York City. Most following week I will be in New York City,
and the following week I might be in Europe, and the week after I will
definately be in Europe.
I will have Internet access in all these places, but my t
William ZHANG wrote:
"Shachar Shemesh" <[EMAIL PROTECTED]> wrote:[EMAIL PROTECTED]
Andreas Pflug wrote:
I wonder if this could be implemented as a wrapper around libpq. This
way, the OLEDB driver would benefit from a proven piece of software.
Regards,
Andreas
That's what I'm doing.
Quoting Bruno Wolff III <[EMAIL PROTECTED]>:
> On Mon, Jan 05, 2004 at 11:32:42 +0500,
> Michael Gill <[EMAIL PROTECTED]> wrote:
> >
> > I think I have found the simple solution by separating the user from the
> > owner of the tables, however!
> >
> > I have simply created tables and function
Manfred Spraul <[EMAIL PROTECTED]> writes:
> I'd agree - convince Bruce and I'll replace the mutexes in thread.c with
> #error.
Most of what I said before was aimed at Bruce ;-)
> But I think libpq should support a mutex around kerberos (or at
> least fail at runtime) - right now it's too easy
"Shachar Shemesh" <[EMAIL PROTECTED]> wrote:[EMAIL PROTECTED]
> Andreas Pflug wrote:
>
> > I wonder if this could be implemented as a wrapper around libpq. This
> > way, the OLEDB driver would benefit from a proven piece of software.
> >
> > Regards,
> > Andreas
>
> That's what I'm doing. I'm not s
Howdy,
Can anyone explain to me when psql tries to convert between encodings?
It seems to disregard encodings set with SET CLIENT_ENCODING.
The following reproduces the behaviour I'm seeing:
1. create an UNICODE database
2. run the following:
set client_encoding to latin1;
create tabl
Eric Ridge kirjutas R, 09.01.2004 kell 01:16:
> Forgetting about composite indexes for a moment, is postgres even
> capable of doing 2 index scans in this situation? Does it know how do
> take the intersection of two scans?
Not currently, but it has been in TODO for quite some time:
* Use bit
Hi all,
We are building security system for a project where the
security is modeled based on the sql-92 GRANT/REVOKE statements.
I was going through the documentation of postgresql related
to GRANT/REVOKE statements.
Following statement says that "with grant option"
is not allowed to
How come --enable-nls in configure is not turned on as default? I don't
think I can name any other program where it's not.
--
/Dennis Björklund
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgres
"Tom Hebbron" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>...
> "Jakub" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > Hi,
> > I need to retrieve the name of the function and the index column names
> > of the functional index. The system information about the
> >
"Jakub" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Hi,
> I need to retrieve the name of the function and the index column names
> of the functional index. The system information about the
> index(function and its args) is stored in the system catalog column
> pg_index.indexprs.
Tom Lane wrote:
Wait a minute. I am *not* buying into any proposal that we need to
support ENABLE_THREAD_SAFETY on machines where libc is not thread-safe.
We have other things to do than adopt an open-ended commitment to work
around threading bugs on obsolete platforms. I don't believe that any
Manfred Spraul <[EMAIL PROTECTED]> writes:
> + * Used to set callback that prevents concurrent access to
> + * non-thread safe functions that libpq needs.
> + * The default implementation uses a libpq internal mutex.
> + * Only required for multithreaded apps on platforms that
> + * do no
Tom Lane wrote:
Personally I find diff -u format completely unreadable :-(. Send
"diff -c" if you want useful commentary.
diff -c is attached. I've removed the signal changes, they are
unrelated. I'll resent them separately.
--
Manfred
Index: src/interfaces/libpq/libpq-fe.h
==
Manfred Spraul <[EMAIL PROTECTED]> writes:
>> return false; /* No threading, so we can't be in send() */
> Why not? Signal delivery can interrupt send() even with single-threaded
> users.
It looks like Bruce left the old logic in place for unthreaded
implementations: we just replace the signal
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> 2. Some people aren't using psql.
> I don't see why this is an issue. People not using psql are either
> using a GUI, which presumably supports plenty of "show" and "describe"
> functionality, or they're writing their own program
Manfred Spraul <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Wouldn't help anyway, if some other part of the app also calls kerberos.
>>
> That's why I've proposed to use the system from openssl: The libpq user
> must implement a lock callback, and libpq calls it around the critical
> section
Tom Lane wrote:
Manfred Spraul <[EMAIL PROTECTED]> writes:
But what about kerberos: I'm a bit reluctant to add a forth mutex: what
if kerberos calls gethostbyname or getpwuid internally?
Wouldn't help anyway, if some other part of the app also calls kerberos.
That's why I've proposed to
"Mark Cave-Ayland" <[EMAIL PROTECTED]> writes:
> 2) Should the statistical data for custom types be stored in the
> pg_statistic table, or should it be the responsibility of the custom
> type to store this in separate tables itself?
You had better have a very, very good reason for proposing the la
Manfred Spraul <[EMAIL PROTECTED]> writes:
> But what about kerberos: I'm a bit reluctant to add a forth mutex: what
> if kerberos calls gethostbyname or getpwuid internally?
Wouldn't help anyway, if some other part of the app also calls kerberos.
I think we should just state that kerberos isn't
Hi everyone,
In response to an email last year (see
http://archives.postgresql.org/pgsql-hackers/2003-10/msg00113.php for
more information), I'm beginning to write a patch for PostgreSQL to
enable people to write their own ANALYZE routines for user-defined
types. In terms of the PostgreSQL "itch a
From fe-secure.c:
/*
* Indicates whether the current thread is in send()
* For use by SIGPIPE signal handlers; they should
* ignore SIGPIPE when libpq is in send(). This means
* that the backend has died unexpectedly.
*/
pqbool
PQinSend(void)
{
#ifdef ENABLE_THREAD_SAFET
libpq needs additional changes for complete thread safety:
- openssl needs different initialization.
- kerberos is not thread safe.
- functions such as gethostbyname are not thread safe, and could be used
by kerberos. Right now protected with a libpq specific mutex.
- dito for getpwuid and stderr
On Sun, 11 Jan 2004, Peter Eisentraut wrote:
> Another problem with pushing psql's queries into the backend is that
> much of the output that psql makes is not a single table. Sometimes
> there is more than one table, or the information is in the table
> footers.
Yes, pushing the \xx commands
27 matches
Mail list logo
