From: | "Thomas G(dot) Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu> |
---|---|
To: | Roland Roberts <roberts(at)panix(dot)com> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] MIN not defined for OID types |
Date: | 1998-09-05 18:50:00 |
Message-ID: | 35F187D8.790116A2@alumni.caltech.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> Yes, well, in this case, it comes about as a result of trying to make
> something database independent. Keystone has functions for both
> PostgreSQL and MySQL, and the MySQL way of doing things seems to be
> limitation. As a result, the DB-independent code does a "select *
> from <table>" then queries to find what the column names are.
> Obviously, we don't need to do it that way with PostgreSQL. My "hack"
> was to change the query so it wouldn't pull back the whole table just
> to find the column names, so I did a "select * from <table> where
> oid=min(oid)".
Ah. Try another hack:
SELECT * from <table> WHERE FALSE;
That will return zero rows but tell you about the columns. Even better,
it won't traverse the table or an index as a min() operation would since
the optimizer can tell apriori that there will be no matching rows.
I haven't done it myself, but psql seems to get the information it needs
about the columns with a query as above. And if that doesn't work then
there will be another trick which does work for you; someone on the list
will tell us :)
- Tom
From | Date | Subject | |
---|---|---|---|
Next Message | Roland Roberts | 1998-09-05 21:35:12 | Re: [HACKERS] MIN not defined for OID types |
Previous Message | Bruce Momjian | 1998-09-05 17:28:22 | new office webcam |