Re: [GENERAL] @ operator

Thanks for reply, it is clear now =) On 09/17/2015 08:34 PM, David G. Johnston wrote: On Thursday, September 17, 2015, David G. Johnston mailto:david.g.johns...@gmail.com>> wrote: On Thursday, September 17, 2015, Антон Бушмелев > wrote: Hello, google nothing for @ operator =(

Re: [GENERAL] @ operator

From: pgsql-general-ow...@postgresql.org [mailto:pgsql-general-ow...@postgresql.org] On Behalf Of ? Sent: Thursday, September 17, 2015 9:11 AM To: pgsql-general@postgresql.org Cc: Антон Бушмелев Subject: [GENERAL] @ operator Hello, google nothing for @ operator =(, what does

Re: [GENERAL] @ operator

On Thursday, September 17, 2015, David G. Johnston < david.g.johns...@gmail.com> wrote: > On Thursday, September 17, 2015, Антон Бушмелев > wrote: > >> Hello, google nothing for @ operator =(, what does this mean field1 <@ >> ( subquery ) ? >> >> > It would depend on what field1 is. > > Typica

Re: [GENERAL] @ operator

Your English is fine. @< is an "array is contained by" operator: http://www.postgresql.org/docs/9.4/interactive/functions-array.html I assume that field1 is an array, as opposed to just a simple value variable. A simple value variable would be tested with something like: field1 IN ( subquery) . T

Re: [GENERAL] @ operator

On Thursday, September 17, 2015, Антон Бушмелев wrote: > Hello, google nothing for @ operator =(, what does this mean field1 <@ > ( subquery ) ? > > It would depend on what field1 is. Typically <@ is a contains/contained-by operator. Is this context the subquery is checked to see if it conta

[GENERAL] @ operator

Hello, google nothing for @ operator =(, what does this mean field1 <@ ( subquery ) ? ps: sorry for my english

Re: [GENERAL] || operator

On Wed, 2014-09-03 at 21:27 -0700, Vinayak wrote: > Hello Pavel, > > Thank you for reply. > >postgres=# select 'abc '::char(7) || 'dbe '::char(6); > >?column? > > > > *abcabc* > >(1 row) > but it gives the result "abcabc". It should be "abcdbe". > > I believe the

Re: [GENERAL] || operator

2014-09-04 11:13 GMT+02:00 Vinayak : > Hi, > > The || operator with arguments (character,character) works fine and even || > operator(character,varchar) also works fine. > but || operator is not working as expected with arguments character data > type and any other data type like integer,smallint,

Re: [GENERAL] || operator

Hi, The || operator with arguments (character,character) works fine and even || operator(character,varchar) also works fine. but || operator is not working as expected with arguments character data type and any other data type like integer,smallint,date,text. Example: postgres=# select 'ab'::char(

Re: [GENERAL] || operator

Yes function should be create or replace function concat_character(character, character) returns text as $$ select concat($1,$2)$$ language sql; Now its working. Thank you. - Regards, Vinayak, -- View this message in context: http://postgresql.1045698.n5.nabble.com/operator-tp5817541p581

Re: [GENERAL] || operator

2014-09-04 6:27 GMT+02:00 Vinayak : > Hello Pavel, > > Thank you for reply. > >postgres=# select 'abc '::char(7) || 'dbe '::char(6); > >?column? > > > > *abcabc* > >(1 row) > but it gives the result "abcabc". It should be "abcdbe". > > yes create or replace f

Re: [GENERAL] || operator

Hello Pavel, Thank you for reply. >postgres=# select 'abc '::char(7) || 'dbe '::char(6); >?column? > > *abcabc* >(1 row) but it gives the result "abcabc". It should be "abcdbe". - Regards, Vinayak, -- View this message in context: http://postg

Re: [GENERAL] || operator

2014-09-03 16:01 GMT+02:00 Kevin Grittner : > Pavel Stehule wrote: > > 2014-09-03 15:25 GMT+02:00 Szymon Guz : > > >> I think we should have this in core, as this definitely is a bug. > > > > hard to say - anything about CHAR(N) is strange, > > On a quick scan of the standard, it looks like our c

Re: [GENERAL] || operator

Pavel Stehule wrote: > 2014-09-03 15:25 GMT+02:00 Szymon Guz : >> I think we should have this in core, as this definitely is a bug. > > hard to say - anything about CHAR(N) is strange, On a quick scan of the standard, it looks like our current behavior is non-conforming. > and this change can

Re: [GENERAL] || operator

On 09/03/2014 06:25 AM, Szymon Guz wrote: Hi Pavel, I think we should have this in core, as this definitely is a bug. It is documented behavior: http://www.postgresql.org/docs/9.3/interactive/datatype-character.html "Values of type character are physically padded with spaces to the sp

Re: [GENERAL] || operator

2014-09-03 15:25 GMT+02:00 Szymon Guz : > > > > On 3 September 2014 15:20, Pavel Stehule wrote: > >> Hi >> >> you can define || operator for char(N) type >> >> postgres=# select oprname, oprleft::regtype, oprright::regtype from >> pg_operator where oprname = '||' >> ; >> oprname | oprleft |

Re: [GENERAL] || operator

On 3 September 2014 15:20, Pavel Stehule wrote: > Hi > > you can define || operator for char(N) type > > postgres=# select oprname, oprleft::regtype, oprright::regtype from > pg_operator where oprname = '||' > ; > oprname | oprleft | oprright > -+-+- > ||

Re: [GENERAL] || operator

Hi you can define || operator for char(N) type postgres=# select oprname, oprleft::regtype, oprright::regtype from pg_operator where oprname = '||' ; oprname | oprleft | oprright -+-+- || | bytea | bytea || | text| text || | te

[GENERAL] || operator

Hello, The behavior of || operator is different in Oracle and PostgreSQL when the arguments are CHAR(n) data type. Example: create table hoge1(col1 char(10), col2 char(10)); insert into hoge1 values('abc', 'def'); select col1 || col2 from hoge1; abcdef (PostgreSQL's result) abc def

FW: [GENERAL] operator is not unique: smallint[] @> smallint[] You might need to add explicit type casts (!)

> -Original Message- > From: Pujol Mathieu [mailto:mathieu.pu...@realfusio.com] > Sent: Dienstag, 15. Juli 2014 08:40 > To: Marc Mamin > Subject: Re: [GENERAL] operator is not unique: smallint[] @> > smallint[] You might need to add explicit type casts (!) >

[GENERAL] operator is not unique: smallint[] @> smallint[] You might need to add explicit type casts (!)

Hello, (Postgres 9.3.4) I don't know how to apply the tip provided along with the error message :-) This issue may be related to the usage of intarray that seems to have added an _int4 @> _int4 operator to public: set search_path=public; select '{1}'::int2[] @> '{1}'::int2[] operator is not u

Re: [GENERAL] Operator based on data type

On Fri, Jan 13, 2012 at 5:27 PM, Craig Ringer wrote: > Oooh, that's clever. Nice! > > People say function overloading is no good They do?? I wrote a similar set of functions to simplify a particular piece of UI code. Three functions called 'str2int'; one takes varchar and returns int, one t

Re: [GENERAL] Operator based on data type

On 12/01/2012 9:20 PM, Daniel McGreal wrote: I have ended up writing a function (more accurately, two functions) which always convert a value into an array, either by returning the array immediately or by nesting it inside one so that all queries can use the second form, above. CREATE OR REPL

[GENERAL] Operator based on data type

Good day! I started off writing a question to this list, but in so doing I thought of a solution! :) So, I'll try and record the result, in case anyone else finds themselves in this unfortunate situation or has suggestions for improvements (especially any regarding query performance). My system g

[GENERAL] Operator based on data type

Good day! I started off writing a question to this list, but in so doing I thought of a solution! :) So, I'll try and record the result, in case anyone else finds themselves in this unfortunate situation or has suggestions for improvements (especially any regarding query performance). My system g

Re: [GENERAL] operator precedence (was: How to use like with a list)

On 11/18/11 12:47 PM, John R Pierce wrote: does ~ have higher expression priority than || or something? speaking of... the precedence table [1] seems somewhat short of operators... the regex operators like ~ ~* etc aren't on there, nor is string concatenation || ... I'd expect the regex p

Re: [GENERAL] operator is not unique: integer || integer

Alban Hertroys schrieb: another example?: RAISE NOTICE "error during validation % :", 'ks:"'||ks||'"@"'||loopdate||'"'; (here LoopDate is a DateTime) Ehm... What's wrong with RAISE NOTICE "error during validation ks:"%"@"%" :', ks, loopdate; ? (I don't quite understand the purpose of that

Re: [GENERAL] operator is not unique: integer || integer

Klint Gore schrieb: > RAISE NOTICE "error during validation % :", 'ks:"'||ks||'"@"'||loopdate||'"'; (here LoopDate is a DateTime) You know you can use more than one % in a raise and it will take care of the data types? yes i know. the real code looks like this: S:='another ABG found on ks

Re: [GENERAL] operator is not unique: integer || integer

another example?: RAISE NOTICE "error during validation % :", 'ks:"'||ks||'"@"'|| loopdate||'"'; (here LoopDate is a DateTime) Ehm... What's wrong with RAISE NOTICE "error during validation ks:"%"@"%" :', ks, loopdate; ? (I don't quite understand the purpose of that colon at the end, btw)

Re: [GENERAL] operator is not unique: integer || integer

Daniel Schuchardt wrote: Tino Wildenhain schrieb: RETURN extract(year FROM $1)*100+extract(month FROM $1)-1; was too clean and easy? ;)) Looks like a good oportunity to clean up your code before anything unexpected happens :-) Cheers T. LOL. Yes I don't like such easy things :-P > RAISE

Re: [GENERAL] operator varchar = integer

Tom Lane schrieb: David Fetter <[EMAIL PROTECTED]> writes: On Mon, May 05, 2008 at 05:26:40PM +0200, Daniel Schuchardt wrote: our db has about 500 functions, 300 tables, 1000 indexes, 1200 Views that all use implicit casting. and: everything is working fine ;-) :-P How do

Re: [GENERAL] operator is not unique: integer || integer

Tino Wildenhain schrieb: RETURN extract(year FROM $1)*100+extract(month FROM $1)-1; was too clean and easy? ;)) Looks like a good oportunity to clean up your code before anything unexpected happens :-) Cheers T. LOL. Yes I don't like such easy things :-P But you see i have a function so

Re: [GENERAL] operator is not unique: integer || integer

Daniel Schuchardt wrote: Tino Wildenhain schrieb: Hi, Daniel Schuchardt wrote: ... in 81: postgres=# SELECT 1::INTEGER||1::INTEGER; ?column? -- 11 (1 row) *shudder* is this actually a port of an application originally targeted at M*Sql? ;) Are you using those columns somewhere with

Re: [GENERAL] operator is not unique: integer || integer

Tino Wildenhain schrieb: Hi, Daniel Schuchardt wrote: ... in 81: postgres=# SELECT 1::INTEGER||1::INTEGER; ?column? -- 11 (1 row) *shudder* is this actually a port of an application originally targeted at M*Sql? ;) Are you using those columns somewhere with their real type - as inte

Re: [GENERAL] operator is not unique: integer || integer

Hi, Daniel Schuchardt wrote: ... in 81: postgres=# SELECT 1::INTEGER||1::INTEGER; ?column? -- 11 (1 row) *shudder* is this actually a port of an application originally targeted at M*Sql? ;) Are you using those columns somewhere with their real type - as integer? I mean if you use the

Re: [GENERAL] operator varchar = integer

Hi, Daniel Schuchardt wrote: Tino Wildenhain schrieb: Hi, ... Comparing int with text in general does not sound like a very good idea to me. It should be quite easy to write a script to identify such places so you can either change the datatypes (preferred) or add the cast. Then rerun your a

Re: [GENERAL] operator varchar = integer

David Fetter <[EMAIL PROTECTED]> writes: > On Mon, May 05, 2008 at 05:26:40PM +0200, Daniel Schuchardt wrote: >> our db has about 500 functions, 300 tables, 1000 indexes, 1200 Views >> that all use implicit casting. and: everything is working fine ;-) >> :-P > How do you know? 8.3 removed the im

Re: [GENERAL] operator varchar = integer

Tino Wildenhain schrieb: Hi, Daniel Schuchardt wrote: David Fetter schrieb: That technical debt is a risk to your whole project, and you need to dedicate resources to paying it down. There are ways to get those automated casts, but they will only

[GENERAL] operator is not unique: integer || integer

yeah, its clear that an upgrade from 8.1 to 8.3 is impossible for us without a major relase. there are to many changes so the whole project has to be rechecked. another example: in 83: postgres=# SELECT 1::INTEGER||1::INTEGER; ERROR: operator does not exist: integer || integer at character 18

Re: [GENERAL] operator varchar = integer

No buts. If you create those automated casts, you are just putting off the inevitable. yes but than it will become a future project. (i think with postgres 8,5 or 8,6 :-P ) You're just confirming the fact that your project is in existential trouble. no, we would get trouble if we upg

Re: [GENERAL] operator varchar = integer

On Mon, May 05, 2008 at 05:26:40PM +0200, Daniel Schuchardt wrote: > David Fetter schrieb: >> That technical debt is a risk to your whole project, and you need >> to dedicate resources to paying it down. >> >> >> >> There are ways to get those automated

Re: [GENERAL] operator varchar = integer

Hi, Daniel Schuchardt wrote: David Fetter schrieb: That technical debt is a risk to your whole project, and you need to dedicate resources to paying it down. There are ways to get those automated casts, but they will only make your situation worse

Re: [GENERAL] operator varchar = integer

David Fetter schrieb: That technical debt is a risk to your whole project, and you need to dedicate resources to paying it down. There are ways to get those automated casts, but they will only make your situation worse in the long run. Cheers, Davi

Re: [GENERAL] operator varchar = integer

On Mon, May 05, 2008 at 11:18:37AM +0200, Daniel Schuchardt wrote: > Hey Group, > > i know what all will say but i need to recreate the = operator for > datatypes varchar and integer in PostgreSQL 8.3. > > Our Software Project has Millions of Lines and so it would be > difficult to check all querie

Re: [GENERAL] operator varchar = integer

Daniel Schuchardt wrote: > i know what all will say but i need to recreate the = operator for > datatypes varchar and integer in PostgreSQL 8.3. > > Our Software Project has Millions of Lines and so it would be > difficult > to check all queries and Datatypes. Also it works really fine > and w

Re: [GENERAL] operator varchar = integer

ups; i have this script but forgott to execute it in the new createt db monday morning thnx. Filip Rembiałkowski schrieb: 2008/5/5 Daniel Schuchardt <[EMAIL PROTECTED] >: Hey Group, i know what all will say but i need to recreate the = operator for

Re: [GENERAL] operator varchar = integer

2008/5/5 Daniel Schuchardt <[EMAIL PROTECTED]>: > Hey Group, > > i know what all will say but i need to recreate the = operator for > datatypes varchar and integer in PostgreSQL 8.3. > > Our Software Project has Millions of Lines and so it would be difficult to > check all queries and Datatypes. A

[GENERAL] operator varchar = integer

Hey Group, i know what all will say but i need to recreate the = operator for datatypes varchar and integer in PostgreSQL 8.3. Our Software Project has Millions of Lines and so it would be difficult to check all queries and Datatypes. Also it works really fine and we all know the risk of wro

Re: [GENERAL] Operator COMMUTATOR - how does postgresql use this information

"Obe, Regina" <[EMAIL PROTECTED]> writes: > Does PostgreSQL use the COMMUTATOR property of an operator to determine > if flip-flopped arguments can be collapsed. No. In recent releases we don't even bother to look for simple duplicate clauses (it's seldom worth the cycles), let alone clauses that

[GENERAL] Operator COMMUTATOR - how does postgresql use this information

Does PostgreSQL use the COMMUTATOR property of an operator to determine if flip-flopped arguments can be collapsed. I used to think it did until someone pointed it doesn't - For example in the below SELECT b.* FROM boszip b INNER JOIN landparcels l ON (b.the_geom && l.the_geom AND l.the_geom

Re: [GENERAL] Operator whit word

Thiago Ventura escribió: > The manual say: > The operator name is a sequence of up to NAMEDATALEN-1 (63 by default) > characters from the following list: > + - * / < > = ~ ! @ # % ^ & | ` ? > > So, how I could create a operator with word ( i.e. LIKE ) ? You can't. (Unless you hack Postgres' sour

[GENERAL] Operator whit word

The manual say: The operator name is a sequence of up to NAMEDATALEN-1 (63 by default) characters from the following list: + - * / < > = ~ ! @ # % ^ & | ` ? So, how I could create a operator with word ( i.e. LIKE ) ? ---(end of broadcast)--- TIP 6:

Re: [GENERAL] Operator performance question

Tom Lane wrote: > Alban Hertroys <[EMAIL PROTECTED]> writes: >> My conclusion is that this query time is mostly limited to the somewhat >> complex COUNT expressions. Is there any way to do this more efficiently? > > Offhand I would bet on the bitstring-AND operations being the > bottleneck; you co

Re: [GENERAL] Operator performance question

Brandon Aiken wrote: > Shouldn't these be using HAVING? > > SELECT COUNT(max_persons) ... > GROUP BY NULL > HAVING max_persons >= 5 AND max_persons <= 8; I don't think so; I need multiple COUNT results for multiple combinations; 5-8 persons isn't the only one. I also need counts for 1-4, 9-12 and

Re: [GENERAL] Operator performance question

Alban Hertroys <[EMAIL PROTECTED]> writes: > My conclusion is that this query time is mostly limited to the somewhat > complex COUNT expressions. Is there any way to do this more efficiently? Offhand I would bet on the bitstring-AND operations being the bottleneck; you could test this by comparing

Re: [GENERAL] Operator performance question

January 09, 2007 11:07 AM To: Postgres General Subject: [GENERAL] Operator performance question Hi all, I need your help on a small performance problem. I have a table of which I have to do a bunch of counts of various conditions. The worst case scenario where I have to iterate over every record i

[GENERAL] Operator performance question

Hi all, I need your help on a small performance problem. I have a table of which I have to do a bunch of counts of various conditions. The worst case scenario where I have to iterate over every record in the table performs just a little bit too slow (800ms). That particular query will be hit a lo

Re: [GENERAL] Operator Class for Hash

"Jozsef Szalay" <[EMAIL PROTECTED]> writes: > Could someone please help me out with an example on how to define an > operator and operator class that supports hash joins? Well, for starters, only the equality operator should be marked HASHES, and the support function for a hash opclass is complete

[GENERAL] Operator Class for Hash

Hi All,   Could someone please help me out with an example on how to define an operator and operator class that supports hash joins? I’ve tried to follow the instructions in the documentation for v8.1 but I’m obviously doing something wrong, because the engine crashes on an operation that

Re: [GENERAL] Operator for int8 array

"S.Thanga Prakash" <[EMAIL PROTECTED]> writes: > We are already in the process of migrating toward 8.1 . > For existing support, we like to support with 7.1.3 . No, just stop right there; your reasonable-sounding premise is utterly not reasonable. You should be making every possible effort

Re: [GENERAL] Operator for int8 array

On Mon, 27 Feb 2006, S.Thanga Prakash wrote: Dear sir, We are already in the process of migrating toward 8.1 . For existing support, we like to support with 7.1.3 . Along with 7.1.3 release, contrib/array has been given for array iterator support for int4 type array. It is working fine

Re: [GENERAL] Operator for int8 array

Dear sir, We are already in the process of migrating toward 8.1 . For existing support, we like to support with 7.1.3 . Along with 7.1.3 release, contrib/array has been given for array iterator support for int4 type array. It is working fine. We changed it similarly, for int8 type array.

Re: [GENERAL] Operator for int8 array

"K.Deepa" <[EMAIL PROTECTED]> writes: > I need operator for int8 array. I tried changing the code in contrib/ > and compiled. > When I tried executing the query, it is dumping. Kindly tell me if there > is alternative > to overcome the problem. I am using postgresql 7.1.3 version. 7.1.3? Egad.

[GENERAL] Operator for int8 array

Dear All, I need operator for int8 array. I tried changing the code in contrib/ and compiled. When I tried executing the query, it is dumping. Kindly tell me if there is alternative to overcome the problem. I am using postgresql 7.1.3 version. -- regards, Deepa K ---(

Re: [GENERAL] operator *=

On 9 Dec 1999, Sascha Ziemann wrote: > Hi, > > I have two tables "user_t" and "email_alias_t". The "user_t" table > has the two fields "last_name" and "linux_login" and the > "email_alias_t" table has the two fields "login" and "alias". > > In some rows in the "user_t" table the entry "linux_

[GENERAL] operator *=

Hi, I have two tables "user_t" and "email_alias_t". The "user_t" table has the two fields "last_name" and "linux_login" and the "email_alias_t" table has the two fields "login" and "alias". In some rows in the "user_t" table the entry "linux_login" is NULL. Now I need all rows from "user_t" an