> > and conn.salt is char[2]. Isn't this a problem?
>
> I don't think it is. Note that it refers to the salt as a "character
> array", not a string. Also, since '_' isn't in the allowed encoding
> set, it can tell the difference between a 9-byte salt and a 2-byte
> salt without a terminating N
Hi, all
I've found a problem in pl/pgsql: the variable declared can't be the
same name of table's column name, here is a example:
---8<
drop table userdata;
create table userdata (
userid text,
txnid text,
passwd text
Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > and conn.salt is char[2]. Isn't this a problem?
> >
> > I don't think it is. Note that it refers to the salt as a "character
> > array", not a string. Also, since '_' isn't in the allowed encoding
> > set, it can tell the difference between a 9-
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > It seems to say that the salt passed to crypt should be null-terminated,
>
> Hmm. The HPUX man page for crypt() just says that
> salt is a two-character string chosen from the set [a-zA-Z0-9./]
> which I think is the traditional spec. Looks
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Look at this from the BSD/OS crypt() manual page:
>
> The crypt function performs password encryption. It is derived from the
> NBS Data Encryption Standard. Additional code has been added to deter
> key search attempts. The first arg
Bruce Momjian <[EMAIL PROTECTED]> writes:
> It seems to say that the salt passed to crypt should be null-terminated,
Hmm. The HPUX man page for crypt() just says that
salt is a two-character string chosen from the set [a-zA-Z0-9./]
which I think is the traditional spec. Looks like BSD h
I said:
> Suppose that we invent a new datatype "regclass", similar to regproc:
> it's actually an OID, but it has the additional implication that it is
> the OID of a pg_class row, and the I/O operations for the type try to
> accept or print a class name not just a numeric OID.
> Next, hack the
Look at this from the BSD/OS crypt() manual page:
The crypt function performs password encryption. It is derived from the
NBS Data Encryption Standard. Additional code has been added to deter
key search attempts. The first argument to crypt is a NUL-terminated
string (norma
Kovacs Zoltan <[EMAIL PROTECTED]> writes:
> Unfortunately I'm getting
> testdb=# select testfunc();
> ERROR: query "SELECT column1 FROM table WHERE column2 LIKE '%anything%'
> ORDER BY column3 LIMIT 1" returned more than one column
This appears fixed in current sources. I believe the relevant
Jan Wieck <[EMAIL PROTECTED]> writes:
> I would've expected you, Tom, to suggest removing it from the
> operators as well :-)
Well, adding a non-standard extension is one thing. Doing it by
removing a different non-standard extension brings up backwards
compatibility issues. In this cas
Tom Lane wrote:
> In any case, this is sufficient reason why we cannot allow $ to be
> allowed in identifiers: it will break any extant applications that use $
> in user-defined operators.
Than again we're no better than the other DB's. The standard
excludes $ from any character clas
On Thu, 16 Aug 2001, Tatsuo Ishii wrote:
> > I have a question, the PostgreSQL encoding name "KOI8" is KOI8-R or
> > KOI8-U or both? I need it for correct alias setting.
>
> I think it's KOI8-R. Oleg, am I correct?
YES
>
> P.S.
> I use Makefile.shlib to create each shared object. This way is,
On Thu, 16 Aug 2001, Tom Lane wrote:
> Oleg Bartunov <[EMAIL PROTECTED]> writes:
> > thanks, please know we prepared a patch for contrib/btree_gist. It fixes
> > memory leak and improve performance. Should I sent it right now or
> > wait until you apply previous patches.
>
> I haven't touched tha
Got it.
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I will try to apply it within the next 48 hours.
>
> I will take responsibility for reviewing and applying this patch. In a
> quick lookover, I saw a few adjustments I wanted to make...
>
> regards, tom lane
>
--
On Thu, 16 Aug 2001, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I will try to apply it within the next 48 hours.
>
> I will take responsibility for reviewing and applying this patch. In a
> quick lookover, I saw a few adjustments I wanted to make...
thanks, please know we p
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Thomas Lockhart writes:
>> Are dollar signs currently allowed in operators? I'd hate to reduce the
>> allowed number of characters for operators.
> They are, therefore identifiers couldn't start or end with a dollar in any
> case. However, single "$
After more than 3 months of hard testing I found a small bug in
PLPGSQL. (It works _too_ fine due to your excellent work... :-) Thanks!)
Consider this function:
CREATE FUNCTION testfunc () RETURNS int4 AS '
declare
ret int4;
begin
ret := column1 FROM table WHERE column2 LIKE ''%anything%''
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I will try to apply it within the next 48 hours.
I will take responsibility for reviewing and applying this patch. In a
quick lookover, I saw a few adjustments I wanted to make...
regards, tom lane
---(
Oleg Bartunov <[EMAIL PROTECTED]> writes:
> thanks, please know we prepared a patch for contrib/btree_gist. It fixes
> memory leak and improve performance. Should I sent it right now or
> wait until you apply previous patches.
I haven't touched that contrib code yet at all. Why don't you just
re
Can this be added to the TODO list? (actually put back on the TODO list)
Along with this email thread?
I feel that it is very important to have BLOB support in postgres that
is similar to what the commercial databases provide. This could either
mean fixing the current implementation or adding
Thanks Bruce,
The lack of tests is more worrying than the lack of reported failures I
reckon. :-( I'll check through the BugTRAQ archives later on.
On a good note however, the Open Source Database Benchmarking project
(osdb.sourceforge.net) has finally gotten around to getting it's code
workin
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> Are dollar signs currently allowed in operators?
Not at present. If they were, you'd have a problem telling whether
"$12" is a parameter identifier or a prefix "$" operator applied to an
integer constant.
However, this is no argument for allowing th
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.
> Hi,
>
> we finished first stage of our proposal for changing of index AM tables
> (see for reference http://fts.postgresq
Thomas Lockhart writes:
> Are dollar signs currently allowed in operators? I'd hate to reduce the
> allowed number of characters for operators.
They are, therefore identifiers couldn't start or end with a dollar in any
case. However, single "$" operator cannot exist, so foo$bar wouldn't be
ambi
> I'm not sure if it's according to or violating the standard.
> But most other databases allow a '$' inside of identifiers.
...
> Objections?
Not an objection really, but...
Are dollar signs currently allowed in operators? I'd hate to reduce the
allowed number of characters for o
> > >
> > > Near the end he gets specifically asked about "Red Hat Database" as a
> > > competitive threat, and he responds that he doesn't think anyone can match
> > > their "investment" of "800 professionals" to work on SQL Server.
> > >
> > > Now I'm sure he didn't mean it to sound this way, bu
On Thu, Aug 16, 2001 at 03:39:28PM +0900, Tatsuo Ishii wrote:
> > I have now some time for implement this my suggestion. Or is better
> > let down this for 7.2? You are right that it's trivial :-)
>
> I think you should target for 7.2.
>
> > Note: My motivate for this is that I have some multi
> Hi all,
>
> Just wondering if anyone knows of or has tested for PostgreSQL buffer
> exploits over the various interfaces (JDBC, ODBC, psql, etc) or directly
> through socket connections?
>
> Working on a sensitive application at the moment, and I've realised I've
> never seen anyone mention te
> Hi,
>
> Dollar in identifier is currently working, you just have to doublequote the
> identifier.
>
> create table "foo$" (
> "foo$" int4
> );
Yes, my guess is that they don't want to double-quote.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED]
On Thu, Aug 16, 2001 at 10:22:48PM +0900, Tatsuo Ishii wrote:
> > I have a question, the PostgreSQL encoding name "KOI8" is KOI8-R or
> > KOI8-U or both? I need it for correct alias setting.
>
> I think it's KOI8-R. Oleg, am I correct?
>
> P.S.
> I use Makefile.shlib to create each shared obje
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> Thanks. BTW, I'm working on for dynamically loading the Unicode
> conversion functions to descrease the runtime memory requirement. The
> reason why I want to do this is:
> o they are huge (--enable-unicode-conversion will increase ~1MB in the
> load mo
On Thu, Aug 16, 2001 at 03:39:28PM +0900, Tatsuo Ishii wrote:
>
> o they are huge (--enable-unicode-conversion will increase ~1MB in the
> load module size)
>
> o nobody will use all of them at once. For example most Japanese users
> are only interested in EUC/SJIS maps.
> --
Good idea.
I
Hi all,
Just wondering if anyone knows of or has tested for PostgreSQL buffer
exploits over the various interfaces (JDBC, ODBC, psql, etc) or directly
through socket connections?
Working on a sensitive application at the moment, and I've realised I've
never seen anyone mention testing PostgreSQL
On Wed, Aug 15, 2001 at 10:39:24AM +0200, John Anderson allegedly wrote:
> AFAIK, OLAP backends essentially provide a cache of denormalised data
> that provide fast access (no need to re-run complex queries) to large
> data sets, and a set of aggregate functions to analyse the data.
>
> There's a
Hi,
Dollar in identifier is currently working, you just have to doublequote the
identifier.
create table "foo$" (
"foo$" int4
);
select * from "foo$";
select "foo$" from "foo$";
works just fine. Or
create table "$foo" (
"$foo" int4
);
select * from "$foo";
select "$foo" from "$foo";
Tom Lane wrote:
> The only downside I can see to this is that it's currently possible to
> use a user-defined type named "serial", if you are determined enough:
>
> create table foo (
> f1 serial, -- it's a serial column
> f2 "serial",-- user-defined type
36 matches
Mail list logo
