, 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://www.enterprisedb.com
Get trained
.
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)
To make changes to your
.
--
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
.
--
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 an appropriate
subscribe-nomail command to [EMAIL
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.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's PostGIS support
=' n_sheet ' AND TOT_N_SHEET=' tot_n_sheet ')
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
an opaque expression. It won't be
able to use any indexes on these columns. Also, incidentally you might want to
use text strings instead of integer labels.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL
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 feeling something was wrong but couldn't put my finger on it
before I hit
was
invented in the Arabic world after all). But other writing systems have some
pretty baroque notations which would be far more difficult to convert.
If anything I would expect this kind of conversion to live in the same place
as things like roman numerals or other more flexible formatting.
--
Gregory
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 http://www.enterprisedb.com
Ask me about EnterpriseDB's On-Demand
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 cover transactionid 118 though.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's On-Demand
) 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 broadcast)---
TIP 6: explain analyze is your friend
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.enterprisedb.com
Get trained by Bruce Momjian - ask me
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 FROM foo WHERE fooid = $1;
$$ LANGUAGE SQL;
Not quite --- it's just returns
catalogs
quite frequently. They're not really well suited for this task.
Alternatively you could create a cursor and play with 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
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 simplest cases.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's
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 since those too.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
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
don't
store anything more in it. text or varchar
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
---(end of broadcast)---
TIP 5: don't forget
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?
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast
(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 http://www.enterprisedb.com
---(end of broadcast