On Thu, 27 Dec 2007 11:39:29 -0500 Andrew Dunstan wrote: > Andreas 'ads' Scherbaum wrote: > >>> i considered this one but this would only bring 0/1 as input, not as > >>> output values, which is what i want. > >>> > >> er, what? This domain would have input and output values of 0/1. > >> > > > > Yes, but i will loose 't', 'true', 'f' and 'false', the usual input > > values in PostgreSQL beside '0' and '1'. It's not that the people don't > > use true/false, they use this a lot. But they expect boolean variable > > in PHP working like a bolean column in PG ... without casts, without > > extra workarounds in the code. > > If your code is prepared to emit t/f but not accept it then that seems > to violate Postel's admonition: "Be *liberal* in what you *accept*, and > *conservative* in what you send."
Andrew: your workaround was to create a domain which would use 0/1 ... this idea will not behave like a boolean, because it does not accept 'true'/'false'. My replacement boolean type does accept all this input values and does emit 0/1 instead of 'f'/'t'. But since i have to create all the casts, operators and classes (like for boolean) again for my data type, i asked if someone know a more elegant way ... if not, i will use my data type. You can see the code here: http://andreas.scherbaum.la/writings/boolean.sql This are some hundred lines of SQL which are almost doubled from the boolean type. So maybe there's a way to avoid all this, but i haven't found one. Kind regards -- Andreas 'ads' Scherbaum German PostgreSQL User Group ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
