>
> > Hello
> >
> > I'have some problems with single-quote,
> > if i insert some text with single-quote ( ' ) error occured !!!
> > thanks
>
> The common way to achieve this is to double up the quotes:
> INSERT INTO table (column) VALUES ('Some ''quoted'' text');
>
I don't try it, but in such
"Colin Price (EML)" wrote:
>
> I have just replicated a db in 6.5 from 6.4.2.
>
> The table selects the date differently from the identical table.
> I obviously set a parameter in 6.4.2 which I now cannot find (from
> mail list archive and doc as well).
>
You've probably done a localization wi
"Colin Price (EML)" wrote:
> I have just replicated a db in 6.5 from 6.4.2.
>
> The table selects the date differently from the identical table.
> I obviously set a parameter in 6.4.2 which I now cannot find (from
> mail list archive and doc as well).
>
> Please aid someone who is tearing his hai
I have just replicated a db in 6.5 from 6.4.2.
The table selects the date differently from the identical table.
I obviously set a parameter in 6.4.2 which I now cannot find (from
mail list archive and doc as well).
Please aid someone who is tearing his hair out.
Thank you in advance,
Colin.
Th
>On Tue, 29 Jun 1999, abdelkrim wrote:
>
>> Hello
>>
>> I'have some problems with single-quote,
>> if i insert some text with single-quote ( ' ) error occured !!!
>> thanks
>>
>>
>>
>
>The common way to achieve this is to double up the quotes:
>
>INSERT INTO table (column) VALUES ('Some ''quoted
On Tue, 29 Jun 1999, abdelkrim wrote:
> Hello
>
> I'have some problems with single-quote,
> if i insert some text with single-quote ( ' ) error occured !!!
> thanks
>
>
>
The common way to achieve this is to double up the quotes:
INSERT INTO table (column) VALUES ('Some ''quoted'' text');
Hello
I'have some problems with single-quote,
if i insert some text with single-quote ( ' ) error occured !!!
thanks
Bruce Momjian wrote:
>
> > Ok. It seems that statistics which is within optimizer's reach is quite
> > poor, so optimizer can't always make sane predictions. And, I am
> > afraid, improving statistics gathering will require major rewrite of code.
> >
> > So there should at least be some way to gi
> Ok. It seems that statistics which is within optimizer's reach is quite
> poor, so optimizer can't always make sane predictions. And, I am
> afraid, improving statistics gathering will require major rewrite of code.
>
> So there should at least be some way to give hints to optimizer,
> shouldn'
Bruce Momjian wrote:
> > -> Index Scan using gindex on btable (cost=2.05 rows=1 width=4)
> > -> Hash (cost=399.00 rows=1 width=4)
> > -> Seq Scan on btable (cost=399.00 rows=1 width=4)
> > -
>
> You can't use in index here because an IN is not select
> But look here:
> -
> adb=> EXPLAIN SELECT * FROM atable WHERE atable.cfield = btable.cfield AND
> atable.afield IN (SELECT btable.bfield WHERE btable.bfield=10);
> NOTICE: QUERY PLAN:
>
> Hash Join (cost=1483.00 rows=1 width=24)
> -> Seq Scan on atable (cost=399.00 rows=
11 matches
Mail list logo
