> the +49 isn't applicable, but not both.
This is the standard format for phone numbers. Parenthesized digits -- as you
suspected -- represent digits which must only be dialled when using the number
locally and must be omitted from outside.
--
Gregory Stark
EnterpriseDB http:/
ks in advance.
You could use a plperl function to use one of the many html parsing perl
modules?
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's 24x7 Postgres support!
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
It's that queries on one side of a join can't refer to tables on the other
side of the join.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's On-Demand Production Tuning
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
people is using inheritance for partitioning support.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's PostGIS support!
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send
a ??
You'll have to explain what you want n_gen to contain.
Then you'll have to decide whether you want to do this in ASP where you can
certainly change the SQL all you like, or on the server where you can have
triggers which change the values being stored or executing additional queries.
;)
For what it's worth your script is a security hole. Look into using query
parameters which in ASP will probably be represented by "?". The method above
will allow hackers to get direct access to your database and do nasty things.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's RemoteDBA services!
---(end of broadcast)---
TIP 6: explain analyze is your friend
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>
>> ORDER BY
>> CASE ?
>> WHEN 1 THEN name ASC
>
> Uh, no, putting the ASC/DESC decoration inside a CASE like that is not
> gonna work
doh! I had a feeli
CASE ?
WHEN 1 THEN name ASC
WHEN 2 THEN name DESC
WHEN 3 THEN height ASC
WHEN 4 THEN height DESC
ELSE id ASC
END
But to the planner this will be basically an opaque expression. It won't be
able to use any indexes on these columns. Also, incidentally you might want to
use text strings ins
pect this kind of conversion to live in the same place
as things like roman numerals or other more flexible formatting.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's 24x7 Postgres support!
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
like intersection to see other
plans which add flag columns. In those cases though they are used by the
direct parent of the node which added it, so the planner can just mark a field
in the parent indicating which column it should look at for the flag.
--
Gregory Stark
EnterpriseDB
do
That's almost the right idea for a last ditch attempt to extract what data you
can from a corrupted table. You have to fill the file with nul bytes though.
Something like dd if=/dev/zero of= bs=1k count=nnn where nnn is, uh, I'm
not sure how large, it won't take much to co
ually to tell the boot scripts what values to store (using sysctl) so
you don't have to run sysctl every time you reboot.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's PostGIS support!
---(end of broadca
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> You're almost there:
>
>> CREATE FUNCTION getfoo (IN int, OUT int, OUT int) returns setof
>> record(int,int) AS $$
>> SELECT fooid, foosubid FRO
e:
CREATE FUNCTION getfoo (IN int, OUT int, OUT int) returns setof record(int,int)
AS $$
SELECT fooid, foosubid FROM foo WHERE fooid = $1;
$$ LANGUAGE SQL;
The return type if present has to match the OUT (and BOTH) parameters.
--
Gregory Stark
EnterpriseDB http://www.enterpri
"Gregory Stark" <[EMAIL PROTECTED]> writes:
> "Andreas Joseph Krogh" <[EMAIL PROTECTED]> writes:
>
>> That's what I'm doing now. I run the query with "limit+1" as limit and if it
>> results in more than limit, I know
between 1 AND 20" is
> rather expensive compared to PG's implementation of LIMIT. Oralce keeps
> snapshot-info in the index, so counting only involves the index AFAIK.
Well that's only going to be true if the index satisfies the whole query which
is not going to be true for the
ith that. But I don't think
that's a great solution either. (yet? I think cursors are getting more useful
in Postgres, perhaps it will be eventually.)
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's RemoteDBA services!
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
"pk_ep07"
>
> Update to a newer PG version, possibly? This symptom has been seen
> before...
It was fixed in these bug-fix releases: 7.4.15, 8.0.10, and 8.1.6 which were
released on August 1st of this year. There have actually been 3 to 4 more
bug-fix releases sinc
"Decibel!" <[EMAIL PROTECTED]> writes:
> On Sep 3, 2007, at 7:26 AM, Gregory Stark wrote:
>> Also, incidentally do you have a good reason to use CHAR instead of varchar
>> or
>> text? char(64) will take 64 bytes (actually 68 bytes in 8.2) even if you
>&g
pace into sections like .co.uk
or .com.au. Canadian domains can be bought directly under .ca like amazon.ca.
I think you'll have to store a specific list of tlds and how deep you want to
look.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(
't see that it's going to be used for a join condition.
Lastly, you could look for a GIST index method for varbit which would be
superior to both of the above tactics. I'm still not sure it would be able to
handle a join clause though, but maybe?
--
d reason to use CHAR instead of varchar or
text? char(64) will take 64 bytes (actually 68 bytes in 8.2) even if you don't
store anything more in it. text or varchar will take only as many bytes as the
data you're storing (plus 4 bytes).
--
Gregory Stark
EnterpriseDB
"Aleksandr Vinokurov" <[EMAIL PROTECTED]> writes:
> Gregory Stark wrote:
>>
>> What version are you running with?
>
> 8.0.1, sorry for missing.
There have been 12 bug-fix releases since then on the 8.0 branch including
updating timezones to reflect the new