type coerce problem with lztext

Поиск
Список
Период
Сортировка
От wieck@debis.com (Jan Wieck)
Тема type coerce problem with lztext
Дата
Msg-id m12P2QD-0003kGC@orion.SAPserv.Hamburg.dsh.de
обсуждение исходный текст
Ответы Re: [HACKERS] type coerce problem with lztext  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: [HACKERS] type coerce problem with lztext  (Don Baccus <dhogaza@pacifier.com>)
Re: [HACKERS] type coerce problem with lztext  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: [HACKERS] type coerce problem with lztext  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Well,
   LZTEXT  is there again, and pg_rewrite uses it for action and   qual strings. This is what it tells:
   pgsql=# select rulename, length(ev_action), octet_length(ev_action)   pgsql-#   from pg_rewrite;       rulename    |
length| octet_length   ----------------+--------+--------------    _RETpg_user    |   3043 |          855
_RETpg_rules  |   3074 |         1139    _RETpg_views   |   4261 |         1252    _RETpg_tables  |   5187 |
1338   _RETpg_indexes |   3525 |         1122   (5 rows)
 
   Yes, the 3043 bytes long rule action string got stored in 855   bytes  in  pg_rewrite.  That's 71.9% compression
rateon this   attempt!
 
   There are functions text(lztext) and  lztext(text)  too,  but   the  system  is  unable  to  find an operator if one
compares  text=lztext in a query. IIRC, creating a  function  named  as   the target type and taking the source type is
whatmade auto-   type-conversion work - so what am I missing here?
 


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#========================================= wieck@debis.com (Jan Wieck) #




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tatsuo Ishii
Дата:
Сообщение: Re: [HACKERS] Changes in 7.0
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] type coerce problem with lztext