"Dan Langille" <[EMAIL PROTECTED]> writes:
> SELECT E.name, EP.pathname, E.id, EP2.pathname, CL.id
> ...
> and EP2.pathname like EP.pathname || '/%'
> I am still suspicous of that like. It seems to be the performance
> killer here. There is an index which can be used:
It won't be, though
I'm not sure that keying off lft is safe in a multi-user environment. I
opted to create and use an objid on the tree definition table, since its
identity is static. I also found that when trees get active, allowing for
tree IDs increased operation speed quite a bit (i actually push this to
two le
On 25 Nov 2002 at 22:15, Dan Langille wrote:
> I know this can be done better, I just can't figure out how. I keep
> thinking of a subselect but I'm totally blocked. It must be bed time.
It's odd what reading the paper, relaxing with a book, and then
trying to sleep can generate. There I was,
Create view WLE_pathnames as
SELECT E.name, EP.pathname
FROM element E,
element_pathnames EP,
watch_list_element WLE
WHERE WLE.watch_list_id = 3724
and WLE.element_id= E.id
and E.id = EP.id;
name | pathname
-
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message
Robert Treat and I came up with a better way to move
nodes from one branch to another inside of a nested tree:
CREATE or REPLACE FUNCTION move_tree (integer, integer) RETURNS text
AS '
-- Mov
On Mon, Nov 25, 2002 at 01:57:28PM -0500, Michael Richards wrote:
> I've got a huge database table and I need to increase the size of a
> varchar from like 100 to 200 characters. As I recall the size is just
> a restriction and doesn't actually affect the format of the table
> file.
>
> Rather
I've got a huge database table and I need to increase the size of a
varchar from like 100 to 200 characters. As I recall the size is just
a restriction and doesn't actually affect the format of the table
file.
Rather than dumping/restoring a 5Gb table with 20,000,000 rows which
will take all
Tilo Schwarz <[EMAIL PROTECTED]> writes:
> - Is it possible to get not only the two tables, but also their corresponding
> two columns involved in a RI-Constraint out of the pg_* tables just with a
> SQL query?
Not easily --- the column info is buried in the pg_trigger.tgargs entries
for the RI t
Dear all,
after reading about the pg_* system tables, I made up a view to see the all
user columns, their type, default value, indices etc. at once (see example
below). Now my first question is:
- Is it possible to get the same result with a simpler / shorter SQL query
than shown below (I'm no
