Fred,
> In PostgreSQL 7.1 Documentation Chapter 8. JDBC Interface the example
> below is used to store a image file into the database. I am using J2SE
> 5.02 and Pervasive Postgres 8 Release 2 with postgresql-8.0-310.jdbc3
> driver. Example 8-2. Using the JDBC Large Object Interface
Why are yo
"Vsevolod (Simon) Ilyushchenko" <[EMAIL PROTECTED]> writes:
> However, when I pg_dump the database and import it on another server,
> the tables are exported alphabetically, so when the 'people_roles' table
> is created with its foreign keys, the table 'roles' does not exist yet.
> Thus, the for
Hi,
As a relative newbie to postgres, I've run into to weirdisms that I
don't quite know how to handle:
1. I have a many-to-many table 'people_roles' containing fields
'person_code' and 'role_code'. It links tables 'people' and 'roles'.
There are foreign key constraints:
ALTER TABLE PEOPLE
In PostgreSQL 7.1
Documentation Chapter 8.
JDBC Interface the example below is
used to store a image file into the database.
I am using J2SE
5.02 and Pervasive Postgres 8 Release 2 with
postgresql-8.0-310.jdbc3 driver.
Example 8-2. Using the JDBC Large Object
Interface
For example, sup
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Rod Taylor wrote:
>> Indeed. A CHECK constraint on a DOMAIN is an ENUM plus some.
> Not really. A domain doesn't create a new type. If you base your enum
> domains on the text type, as would usually be the case, then nothing
> stops you from using
Rod Taylor wrote:
> Indeed. A CHECK constraint on a DOMAIN is an ENUM plus some.
Not really. A domain doesn't create a new type. If you base your enum
domains on the text type, as would usually be the case, then nothing
stops you from using, say, text concatenation operators and the like.
I
On Wed, 2005-06-29 at 09:22, Russell Simpkins wrote:
> fair enough. but a simple order by id would never work.
>
Try this:
select *,
case
when id=2003 then 1
when id=1342 then 2
when id=799 then 3
when id=1450 then 4
On Wed, Jun 29, 2005 at 10:22:07AM -0400, Russell Simpkins wrote:
>
> fair enough. but a simple order by id would never work.
I didn't mean to imply that it would -- I meant only that
ORDER BY is necessary to guarantee a particular
row order.
--
Michael Fuhr
http://www.fuhr.org/~mfuhr/
---
fair enough. but a simple order by id would never work.
From: Michael Fuhr <[EMAIL PROTECTED]>
To: Russell Simpkins <[EMAIL PROTECTED]>
CC: pgsql-sql@postgresql.org
Subject: Re: [SQL] ORDER records based on parameters in IN clause
Date: Wed, 29 Jun 2005 05:57:23 -0600
On Wed, Jun 29, 2005 at 07
On Wed, 2005-06-29 at 10:21 -0300, Martín Marqués wrote:
> El Mié 29 Jun 2005 09:40, KÖPFERL Robert escribió:
> >
> > |
> > |I personally think that the ENUM data type is for databases
> > |that are not well
> > |designed. So, if you see the need for ENUM, that means you
> > |need to re-think
Please keep replies copied to the list unless you have a specific reason
not to. This lets more people potentially help you and lets others
learn from the discussion.
On Wed, Jun 29, 2005 at 14:09:16 +0530,
Mukesh Ghatiya <[EMAIL PROTECTED]> wrote:
> Hi Bruno,
>
> Thanks for the response. Ok, l
El Mié 29 Jun 2005 09:40, KÖPFERL Robert escribió:
>
> |
> |I personally think that the ENUM data type is for databases
> |that are not well
> |designed. So, if you see the need for ENUM, that means you
> |need to re-think
> |your data design.
> |
>
> I disagree. In several relations (views o
Hi,
I've a prolem inserting records in a view using different ways.
I want to insert either way, with PK given and without PK which should then
be taken by its DEFAULT stanza:
insert into a_and_b(a) values (537)# id not given, self assigned
insert into a_and_b(x) values (true)# id not give
|
|I personally think that the ENUM data type is for databases
|that are not well
|designed. So, if you see the need for ENUM, that means you
|need to re-think
|your data design.
|
I disagree. In several relations (views of the world) one needs to have a
hand full of well defined values while
SELECT
table.*
FROM
table
JOIN (SELECT id, count(id) AS count FROM... your subquery) AS x
ORDER BY
x.count
Bye.
Sorry: I forgot join condition:
SELECT
table.*
FROM
table
JOIN (SELECT id, count(id) AS count FROM... your subquery) AS x ON
(table.id = x.id)
ORDER BY
Riya Verghese wrote:
select * from table where id IN (2003,1342,799, 1450)
I would like the records to be ordered as 2003, 1342, 799, 1450. The
outer query has no knowledge of the count(id) that the inner_query is
ordering by.
I think this is the real problem: outer query must know count(id)
On Wed, Jun 29, 2005 at 07:19:22AM -0400, Russell Simpkins wrote:
>
> Order by id will not do what you want, but this should.
> Select * from table where id = 2003;
> Union all
> Select * from table where id = 1342;
> Union all
> Select * from table where id = 799;
> Union all
> Select * from tabl
On 6/27/05, Riya Verghese <[EMAIL PROTECTED]> wrote:
> I have a stmt where the outer-query is limited by the results of the inner
> query. I would like the outer query to return records in the same order as
> the values provided in the IN clause (returned form the inner query).
>
> The inner_quer
>> when I say
>> select * from table where id IN (2003,1342,799, 1450)
>> I would like the records to be ordered as 2003, 1342, 799, 1450.
>Just say:
>select * from table where id IN (2003,1342,799, 1450) ORDER BY id;
>If that doesn't work, you will have to be more specific and send us the
exact qu
On 6/28/05, Martín Marqués wrote:
> El Mar 28 Jun 2005 13:58, PFC escribió:
> > Personnally I use one table which has columns (domain, name) and which
> > stores all enum values for all different enums.
> > I have then CHECK( is_in_domain( column, 'domain_name' )) which is a
> > simple
20 matches
Mail list logo
