Re: Feeding results back into select - Mailing list pgsql-hackers

From Teodor Sigaev
Subject Re: Feeding results back into select
Date
Msg-id 48AFE0AE.7060300@sigaev.ru
Whole thread Raw
In response to Re: Feeding results back into select (was: proposal sql: labeled function params)  ("D'Arcy J.M. Cain" <darcy@druid.net>)
Responses Re: Feeding results back into select  ("D'Arcy J.M. Cain" <darcy@druid.net>)
List pgsql-hackers
>> select 'a'=>'b';
>>    ?column?
>> ----------
>>    "a"=>"b"



> 
> Branching the topic, I have a question about this.  I haven't studied
> hstore extensively but this seems like a problem on it's face.
> Shouldn't you be able to take the result of a select and pass it back
> to a select?  I mean, what happens if you do this?
> 

"a"=>"b" is a value of hstore type, so query should be:
select '"a"=>"b"'::hstore;

" character was chosen to simplify escaping,

> I ran into a similar issue with my chkpass type (see contrib) where the
> string inserted into the field is stored encrypted with functions to
> test for equality basically like the Unix password model works.  If I
> just displayed raw strings then a dump and reload would have trashed
> all the passwords by re-encrypting them.  What I did was to make a
> special case on input.  If the string started with ':' then I strip
> that character and insert the string unchanged.  Then I changed the
> output to prepend the ':'.  Now dump and reload work.

I see, but your problem is that password is one-way encrypted, so, you 
definitely need to distinguish already encrypted strings. Hstore hasn't that 
problem.




-- 
Teodor Sigaev                                   E-mail: teodor@sigaev.ru
  WWW: http://www.sigaev.ru/
 


pgsql-hackers by date:

Previous
From: Tatsuo Ishii
Date:
Subject: Re: WITH RECURSIVE patches 0818
Next
From: Peter Eisentraut
Date:
Subject: Re: proposal sql: labeled function params