I apologize if this is sent twice.
The simplest solution would be to use a view over the data hiding the
mess of the case statement so that ad-hoc users' queries would still work.
- Bill
Bob Smith, Hammett & Edison, Inc. wrote:
>On Thu, Dec 20, 2001, 18:55:18 Tom Lane wrote:
>
>>[EMAIL PROTE
[EMAIL PROTECTED] (Bob Smith, Hammett & Edison, Inc.) writes:
> Here is the problem I'm trying to solve, perhaps someone can help.
> For an invoicing system database, I have a table that defines
> employees. Each has a begin and end date defining the employment
> period. For current employees, t
On Thu, Dec 20, 2001, 18:55:18 Tom Lane wrote:
>[EMAIL PROTECTED] (Bob Smith, Hammett & Edison, Inc.) writes:
>> On a related note, does anyone know if 'current' works with DATE?
>
>DATE does not have an internal representation of 'current', so the DATE
>input parser treats it the same as 'now'.
On Thu, 20 Dec 2001, Bruno Wolff III wrote:
> On Thu, Dec 20, 2001 at 04:24:33PM -0800,
> "Bob Smith, Hammett & Edison, Inc." <[EMAIL PROTECTED]> wrote:
> > See example below of using NULL values with type DATE. It behaves
> > strangely in expressions, "(x <> null)" gives an entirely differen
[EMAIL PROTECTED] (Bob Smith, Hammett & Edison, Inc.) writes:
> On a related note, does anyone know if 'current' works with DATE?
DATE does not have an internal representation of 'current', so the DATE
input parser treats it the same as 'now'. AFAIR only timestamp (nee
datetime) has that concept
I think that this page will explain it all:
http://www.postgresql.org/idocs/index.php?functions-comparison.html
|On 011220 17:05
|Bob Smith, Hammett & Edison, Inc. ([EMAIL PROTECTED]) wrote the following...
|
|See example below of using NULL values with type DATE. It behaves
|strangely in expres
On Thu, Dec 20, 2001 at 04:24:33PM -0800,
"Bob Smith, Hammett & Edison, Inc." <[EMAIL PROTECTED]> wrote:
> See example below of using NULL values with type DATE. It behaves
> strangely in expressions, "(x <> null)" gives an entirely different
> result than "not(x = null)". Is this intended beh
See example below of using NULL values with type DATE. It behaves
strangely in expressions, "(x <> null)" gives an entirely different
result than "not(x = null)". Is this intended behavior, if so, why?
If not, is this a bug?
On a related note, does anyone know if 'current' works with DATE? Wit
We do something similar. What we do is create tables for the different
companies (with an underscore as first char). Then we create a meta-lookup
table that maps the customer_id to the correct table name.
There are some real big problems with this.
1. Tier 1 looks ugly, very ugly.
2. It takes som
You might want to take a look at your pg_hba.conf file to see if the
auth-method is "trust".
Details are here:
http://www.postgresql.org/idocs/index.php?client-authentication.html#PG-HBA.
CONF
-Nick
--
Nick Fankhauser [EM
Title: RE: [ADMIN] user passwords
take a look at http://archives.postgresql.org/pgsql-admin/2001-09/msg00095.php
-Original Message-
From: Jodi Kanter [mailto:[EMAIL PROTECTED]]
Sent: quinta-feira, 20 de dezembro de 2001 14:19
To: Postgres Admin List
Subject: [ADMIN] user passwords
why is it that I can sign in to the postgres database using PSQL without
having to specify a password for a user even thought one has been specified
in pg_shadow?
I signed in to Linux with my own personal id (which is NOT a postgres
account) and used the following command to get in:
psql -U post
on 12/19/01 11:08 AM, Tom Lane at [EMAIL PROTECTED] wrote:
> Randall Perry <[EMAIL PROTECTED]> writes:
>> Anyone know what this means:
>> getTables(): SELECT (funcname) for trigger cust_modification_date returned 0
>> tuples. Expected 1.
>
> It would seem you have dropped the function which that
I don't know what your application looks like, but we're handling a similar
situation by using several databases in a single cluster. In our case, the
apps are JDBC-based, so it is possible to open a connection pool to each
database & easily point the same application code at different sources. Th
14 matches
Mail list logo
