Is there a reason that the expressions:
Crops.change_e > '10/1/2001'
'10/1/2001' < Crops.change_e
when used in a WHERE clause of a query should yield
a good plan for the first and a bad plan for the second?
They both yield the same boolean value.
The attribute Crops.change_e is not involved
Here's a lovely message I got from `psql':
g9genarc@eddie:~$ psql -h /var/pgsql --help
psql was compiled without support for long options.
Use --help for help on invocation options.
I guess that it was confused by having both options at once, since
"psql --help" works fine (i.e. the long o
i am at presemrt devlping a sever side pgmg using servlets. The database used is
postgres. I would like to know how to hide the tables from theother users. Kindly send
me how to hide tables in postgres. Thanx in advance.Bye
---(end of broadcast)---
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> Here's a lovely message I got from `psql':
>
> g9genarc@eddie:~$ psql -h /var/pgsql --help
> psql was compiled without support for long options.
> Use --help for help on invocation options.
Looks as though --help and --verbose always work, n
"ag20" <[EMAIL PROTECTED]> writes:
> Is there a reason that the expressions:
> Crops.change_e > '10/1/2001'
> '10/1/2001' < Crops.change_e
> when used in a WHERE clause of a query should yield
> a good plan for the first and a bad plan for the second?
I think you have a broken installation. I
Arcady Genkin writes:
> g9genarc@eddie:~$ psql -h /var/pgsql --help
> psql was compiled without support for long options.
> Use --help for help on invocation options.
>
> I guess that it was confused by having both options at once, since
> "psql --help" works fine (i.e. the long options *do
-- Start of PGP signed section.
> > Here's a lovely message I got from `psql':
> >
> > g9genarc@eddie:~$ psql -h /var/pgsql --help
> > psql was compiled without support for long options.
> > Use --help for help on invocation options.
>
> Looks as though --help and --verbose always work, no
Tom Lane writes:
> Peter, what do you think of hacking psql to only try the pg_description
> actions if pset.issuper? The alternative is to invent COMMENT ON LARGE
> OBJECT, which is more work than I have time for at the moment.
Sounds reasonable.
--
Peter Eisentraut [EMAIL PROTECTED] htt
ag20 wrote:
> Is there a reason that the expressions:
>
> Crops.change_e > '10/1/2001'
>
> '10/1/2001' < Crops.change_e
>
> when used in a WHERE clause of a query should yield
> a good plan for the first and a bad plan for the second?
Disclaimer: I'm tired and haven't tested this.
This "probl
