Michael Orlitzky wrote:
> We use Postgres for shared hosting; i.e. what most people use MySQL for.
> The biggest headache for us so far has been that we're unable to get
> group permissions set up effectively so that different groups of
> customers, admins, apaches, etc. can access/modify the data
Kenneth Tilton wrote:
> We want to make sure no two examiners are working on the same case at
> the same time, where the
> cases are found by searching on certain criteria with limit 1 to get the
> "next case".
>
> A naive approach would be (in a stored procedure):
>
>
bhanu udaya wrote:
>>> What is the best way of doing case insensitive searches in postgres using
>>> Like.
>>
>> Table "laurenz.t"
>> Column | Type | Modifiers
>> +-+---
>> id | integer | not null
>> val | text | not null
>> Indexes:
>> "t_pkey" PRIMARY KEY, btree (id)
>>
>
On Mon, Jul 1, 2013 at 10:01 AM, Albe Laurenz wrote:
> bhanu udaya wrote:
What is the best way of doing case insensitive searches in postgres using
Like.
>>>
>>> Table "laurenz.t"
>>> Column | Type | Modifiers
>>> +-+---
>>> id | integer | not null
>>> val | text
Ingmar Brouns wrote:
>> My solution is fast and efficient, it will call upper() only once
>> per query. I don't see your problem. Different database systems
>> do things in different ways, but as long as you can do what you need
>> to do, that should be good enough.
> I was toying around a littl
On 06/30/2013 09:56 PM, Andrew Sullivan wrote:
> On Sun, Jun 30, 2013 at 09:31:18PM -0400, Michael Orlitzky wrote:
>> (why do I get the feeling nobody is going to check out the repo):
>
> Probably because you're asking random strangers on the Internet to
> help you solve their problems, and many o
On 07/01/2013 03:36 AM, Albe Laurenz wrote:
>
> I took a look, but it takes more time than I'm willing to spend
> to actually get to your problem.
>
> Could you outline briefly what the problem is?
>
(I'm going to copy from the README a bit, but I'll try to pare it down)
I want to be able to c
On Mon, Jul 01, 2013 at 09:34:24AM -0400, Michael Orlitzky wrote:
> >> # Admins can do anything.
> >
> > You've been able to create this situation with the superuser flag for
> > as long as I can remember (I started with Postgres in the 6.5.x era,
> > but I won't claim my memory goes back that
Hello,
I've lost some time to debug a large Query with many CTE.
I couldn't really believe the error message.
it was correct after all , though surprising.
a short version to illustrate my error:
WITH t1 (a,b) AS (
SELECT
1 as x,
2 as a,
On 07/01/2013 10:21 AM, Andrew Sullivan wrote:
>
> So not "can do anything", but can read and write any database. Looks
> to me to be something like
>
>CREATE ROLE adminuser NOSUPERUSER NOCREATEDB NOCREATEROLE
>NOCREATEUSER INHERIT LOGIN NOREPLICATION ADMIN;
>
> Whenever a database is c
Marc Mamin-2 wrote
> Hello,
>
> I've lost some time to debug a large Query with many CTE.
> I couldn't really believe the error message.
>
> it was correct after all , though surprising.
> a short version to illustrate my error:
>
> WITH t1 (a,b) AS (
> SELECT
>
Hello:
I have question for cmin and cmax.
It is said:
cminis: The command identifier (starting at zero) within the
inserting transaction.
cmax is: The command identifier within the deleting transaction, or
zero.
http://www.postgresql.org/docs/9.1/static/ddl-system-columns.html
Hello:
I looked into the source code, and I think I now understand it:
cmin and cmax are same! The documentation is too old now.
I made another test:
In terminal A:
pgsql=# begin;
BEGIN
pgsql=# select * from tab01;
id | cd
+
(0 rows)
pgsql=# select xmin,xmax,cmin,cmax,* from tab01;
xmi
On Tue, Jul 2, 2013 at 5:19 AM, 高健 wrote:
> Hello:
> I looked into the source code, and I think I now understand it:
> cmin and cmax are same! The documentation is too old now.
Yes, you figured it out.
For short: cmin and cmax are overlapped fields and are used within the
same transaction to iden
14 matches
Mail list logo
