Ian Lance Taylor [EMAIL PROTECTED] wrote:
Dwayne Miller [EMAIL PROTECTED] writes:
Well, for one I have no idea what cygwin is, or what it does to
your system, or what security vulnerabilities it might add to your
system. It comes with alot of stuff that I may or may not need, but
Hi
Please help me compose the query in PostgreSQL.
Using PostgreSQL 7.1.2.
Suppose relations A and B have columns:
{X1, X2, ..., Xm, Y1, Y2, ..., Yn}
and
{Y1, Y2, ..., Yn}
Attributes Y1, Y2, ..., Yn are common for both relations
and have the same type in both.
How can I define in
Hi
The following is the quote describing WHERE clause of SELECT
(pgsql/doc/html/sql-select.html).
WHERE Clause
The optional WHERE condition has the general form:
WHERE boolean_expr
boolean_expr can consist of any expression which evaluates to a boolean value. In many
cases,
this
Dwayne Miller [EMAIL PROTECTED] writes:
Well, for one I have no idea what cygwin is, or what it does to
your system, or what security vulnerabilities it might add to your
system. It comes with alot of stuff that I may or may not need, but
what components I need to run Postgres
hello All
I tried the following commands:
ponto=# explain select * from horarios where funcionario1;
NOTICE: QUERY PLAN:
Seq Scan on horarios (cost=0.00..176.21 rows=2432 width=132)
EXPLAIN
ponto=# explain select * from horarios where funcionario=1;
NOTICE: QUERY PLAN:
Index Scan
Ken Hirsch [EMAIL PROTECTED] writes:
(To be honest, the idea of worrying about security vulnerabilities on
Windows seems odd to me. If you are honestly worried about security
on your database server, the first step is to stop running Windows.)
That's just a cheap shot. I've seen no
I seem to have the complete released (I think) SQL99 docs. If anyone wants
them - just reply to me personally. Should they be put on the postgres
site? Is that legal?
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Ken Hirsch
Sent: Sunday,
gabriel writes:
So my question is why in the first case the postgre did'nt use the index
and made a seq scan ??
Because it thinks the sequential scan will be faster. You didn't show any
evidence to the contrary.
--
Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter
hello All
I tried the following commands:
ponto=# explain select * from horarios where funcionario1;
NOTICE: QUERY PLAN:
Seq Scan on horarios (cost=0.00..176.21 rows=2432 width=132)
EXPLAIN
ponto=# explain select * from horarios where funcionario=1;
NOTICE: QUERY PLAN:
Peter Eisentraut [EMAIL PROTECTED] writes:
Florian Weimer writes:
The first version escaped ' with ''. I changed it when I noticed that
if \' is used instead, the same function can be used for strings
('...') and identifiers (...).
Last time I checked (15 seconds ago), you could not
Bruce Momjian [EMAIL PROTECTED] writes:
OK, can you supply an updated patch?
Yes, I'm going to update it. Shall I post it here?
Sure, or patches list.
Could anybody have a look at the parser issue?
I am unsure how it is supposed to behave. Comments? Does the standard
say anything?
Ian Lance Taylor ( others) wrote:
This is true. However, a process-pool architecture would benefit
Postgres
on other platforms besides Windows. Postgresql has been ported to the
HP3000 MPE/iX operating system, for example, which is POSIX-compliant,
but
has an awfully slow fork().
On
Dave Blasby [EMAIL PROTECTED] writes:
CREATE TABLE test_table (myint integer, mydata MY_DATATYPE);
INSERT INTO test_table VALUES (1);
At this point, I'd expect there to be one row in test table. The myint
column will have the value one, and the mydata column will have the
value NULL.
OK, can you supply an updated patch?
Peter Eisentraut [EMAIL PROTECTED] writes:
Florian Weimer writes:
The first version escaped ' with ''. I changed it when I noticed that
if \' is used instead, the same function can be used for strings
('...') and identifiers (...).
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
Hello, i just reviewed the win32 errno patch and i saw that maybe i didn't
really played it totally safe in my last
Martin Weinberg [EMAIL PROTECTED] writes:
DumpComment: SELECT failed: 'ERROR: dtoi4: integer out of range
Hmm. I can reproduce this error message if I suppose that you have
OIDs exceeding 2 billion. pg_dump will produce queries like:
regression=# select * from pg_description where objoid =
Florian Weimer writes:
In addition, there seems to be a bug in the treatment of escapes in
identifiers. 'SELECT ;' yields the error message 'Attribute ''
not found ' (not ''!) or even 'Attribute '\' not found', depending
on the queries executed before.
A bug indeed.
RCS file:
Vladimir V. Zolotych wrote:
Please give me hints how can I use conditional operators ALL, ANY in
WHERE clause.
[This query would have been better directed to the pgsql-sql list.]
Some examples will be appreciated.
ALL is used to test a value against all of a list of items.
Find the
Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes:
I think actually the backend parser has no business changing
constants, he is imho only allowed to parse it, so he knows
where a constant begins, and where it ends.
How do you propose to handle embedded quote marks in literals,
if there
Peter Eisentraut [EMAIL PROTECTED] writes:
A bug indeed.
xd{xddouble} {
- addlit(yytext, yyleng-1);
+ addlit(yytext+1, yyleng-1);
}
I don't follow. xddouble can only expand to two
Where did we leave this?
On Tue, Aug 28, 2001 at 11:07:32AM +0200, Joerg Hessdoerfer wrote:
Hi!
Please find attached some very simple encoders/decoders for bytea and base64.
Bytea encoder is very picky about what it leaves unescaped - basically the
base64
char set ;-)
Since
Tom Lane writes:
Peter Eisentraut [EMAIL PROTECTED] writes:
A bug indeed.
xd{xddouble} {
- addlit(yytext, yyleng-1);
+ addlit(yytext+1, yyleng-1);
}
I don't follow.
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane writes:
I don't follow. xddouble can only expand to two quote marks, so how
does it matter which one we use as the result?
addlit() expects the first argument to be null-terminated and implicitly
uses that null byte at the end of the
Bruce Momjian [EMAIL PROTECTED] writes:
Where did we leave this?
I don't think adding a datatype just to provide base64 encoding is
a wise approach. The overhead of a new datatype (in the sense of
providing operators/functions for it) will be much more than the
benefit. I think providing
Bruce Momjian [EMAIL PROTECTED] writes:
Where did we leave this?
I don't think adding a datatype just to provide base64 encoding is
a wise approach. The overhead of a new datatype (in the sense of
providing operators/functions for it) will be much more than the
benefit. I think
Already handled. I ran it on proc.c and got:
MyProc-errType = STATUS_OK;/* initialize result for success */
The feature was added with:
# add space after comments that start on tab stops
sed 's,;\(/\*.*\*/\)$,; \1,' |
I must have added this since
Thanks you your description, I have added a bytea section to the docs.
Patch attached.
For bytea, follow this rule: to escape a null character, use this:
'\\0'. To escape a backslash, use this: ''.
Same idea to unescape data.
Are there other characters that need to be
I don't think adding a datatype just to provide base64 encoding is
a wise approach. The overhead of a new datatype (in the sense of
providing operators/functions for it) will be much more than the
benefit. I think providing encode/decode functions is sufficient...
and we have those
I don't think adding a datatype just to provide base64 encoding is
a wise approach. The overhead of a new datatype (in the sense of
providing operators/functions for it) will be much more than the
benefit. I think providing encode/decode functions is sufficient...
and we have those
\\012In my early tests 0x0a (LF) was getting converted to 0x20
(space).
I think this was happening during PHP's parsing, but I'm still not sure.
I'll dig into this some more later.
redfaced
The script I was using in PHP *explicitly* converted all linefeeds to
spaces. Mystery
Joe Conway [EMAIL PROTECTED] writes:
I was thinking it would be nice to have a
way to cast bytea into text and vice-versa,
How will you handle a null byte in bytea data? Transforming it directly
into an embedded null in a text object is NOT an acceptable answer,
because too many of the text
Bruce Momjian [EMAIL PROTECTED] writes:
However, there's a trap: before things get to bytea input handler, they
are first processed by postgresql general parser.
This description fails to make clear that the two levels of parsing only
apply for datums that are written as string literals in SQL
It might be nice to have a PQbyteaEscape or some such function available
in
the libpq client library so that arbitrary binary could be escaped on
the
client side and used in a sql statement. I actually wrote this already
as an
addition to the PHP PostgreSQL extension, but it would make
Bruce Momjian [EMAIL PROTECTED] writes:
However, there's a trap: before things get to bytea input handler, they
are first processed by postgresql general parser.
This description fails to make clear that the two levels of parsing only
apply for datums that are written as string literals
Below is the last message I sent (to patches) regarding the random string
function for contrib. Is there any interest in this? I don't mind changing
it per Peter's comments, but I don't want to bother if no one sees any value
in it. Comments?
-- Joe
- Original Message -
From: Joe Conway
35 matches
Mail list logo
